EML: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-04-15T22:41:40ZEcoinformatics Redmine
Redmine Bug #4939 (New): buildDocBook.xsl missing from release distributionhttps://projects.ecoinformatics.org/ecoinfo/issues/49392010-04-15T22:41:40ZMatt Jonesjones@nceas.ucsb.edu
<p>Gallagher reports:</p>
<p>Anyway, the file buildDocBook.xsl is missing from the tar.gz dist of eml<br />2.1.0. This shows when the clean target is run because that target<br />erases the docs. The docs target requires the xsl...</p> Bug #4433 (New): children element with namespace prefix were considered invalid by parserhttps://projects.ecoinformatics.org/ecoinfo/issues/44332009-10-01T20:25:11ZJing Taotao@nceas.ucsb.edu
<p><?xml version="1.0"?><br /><eml:eml packageId="tao.12926.1" system="knb" xmlns:eml="eml://ecoinformatics.org/eml-2.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="eml://ecoinformatics.org/eml-2.1.0 eml.xsd"><br /> <dataset><br /> .......<br /> </dataset><br /></eml:eml></p>
<p>The above xml instance will be considered valid.</p>
<p>However, if we add "eml" to "dataset" and xml will look like:<br /><?xml version="1.0"?><br /><eml:eml packageId="tao.12926.1" system="knb" xmlns:eml="eml://ecoinformatics.org/eml-2.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="eml://ecoinformatics.org/eml-2.1.0 eml.xsd"><br /> <eml:dataset><br /> .......<br /> </eml:dataset><br /></eml:eml></p>
<p>Parser will give an error like:<br />cvc-complex-type.2.4.a: Invalid content starting with element 'eml:dataset'. The content must match '((("":access){0-1},(((("":dataset)|("":citation))|("":software))|("":protocol))),("":additionalMetadata){0-UNBOUNDED})'</p> Bug #3855 (New): Create an EML Utilities modulehttps://projects.ecoinformatics.org/ecoinfo/issues/38552009-03-03T20:14:33ZMargaret O'Brienmob@msi.ucsb.edu
<p>For a while, it has been recognized that the EML schema should be developed independently from the xsl stylesheets. For the March release of EML/Metacat/Morpho, the following tag was created for these:<br />RELEASE_EML_UTILS_1_0_0_RC1<br />default.css<br />styles/*xsl<br />eml201to210.xsl<br />ascii-treeview.xsl<br />branding.js<br />default.js</p>
<p>This tag is probably adequate for Metacat and Morpho<br />In addition to the xsl stylesheets for displaying html, eml/styles/ includes subdirectories for converting between different versions of EML and between EML and other XML, like nbii and esri. So the structure of Utilities needs to be decided that can hold various material. One possible structure for utilities could be:<br />eml/utilities<br />eml/utilities/display<br />eml/utilities/display/styles<br />eml/utilities/conversions<br />eml/utilities/conversions/beta6toeml2<br />eml/utilities/conversions/eml20toeml210</p> Bug #3508 (New): create a stylesheet for EML2.0.x to EML 2.1.0https://projects.ecoinformatics.org/ecoinfo/issues/35082008-10-06T23:33:43ZMargaret O'Brienmob@msi.ucsb.edu
<p>there are 4 changes in EML 2.1.0 which need to be addressed in a transformation stylesheet. Summarized:<br />1. datetime -> dateTime (bug <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: datetime element does not use consistent naming (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/1152">#1152</a>)<br />2. new additionalMetadata/metadata element (bug <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: use of <any> in additionalMetadata is invalid (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/2054">#2054</a>)<br />3. method -> methods (bug <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: Inconsistent naming of "method"(s) element (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/2568">#2568</a>)<br />4. access trees moved (bug <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: fix access control rule ambiguities (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/1132">#1132</a>)</p>
<p>Detailed:<br />1. xpath in instance docs: <br />/eml/dataset/dataTable/attributeList/attribute/measurementScale/datetime <br />becomes .../dateTime</p>
<p>2. xpath in instance docs (* neq <describes>): <br />/eml/additionalMetadata/* becomes /eml/additionalMetadata/metadata/*</p>
<p>3. method was declared in entity group, so all these paths become "methods":<br />eml/dataset/dataTable/method <br />eml/dataset/spatialRaster/method <br />eml/dataset/spatialReference/method <br />eml/dataset/spatialVector/method <br />eml/dataset/view/method <br />eml/dataset/storedProcedure/method</p>
<p>4. access trees moved:<br />case 1: access tree at resource level:<br />/eml/dataset/access and /eml/software/access moved to eml/access</p>
<p>case 2: access tree(s) in additionalMetadata sections:<br />Current behavior:<br />Do not recognize <access> siblings of additionalMetadata/describes that reference <br />/eml/dataset/distribution <br />/eml/software/distribution</p>
<p>Recognize <access> siblings of additionalMetadata/describes that reference<br />/eml/dataset/dataTable/physical/distribution<br />/eml/software/implementation/distribution</p>
<p>recognizable cases:<br />4.2.1.one additionalMetadata/describes element pointing a recognized node, with one sibling access tree<br />action: move the access tree, remove additionalMetadata section</p>
<p>4.2.2. two (or more) additionalMetadata/describes elements pointing to recognized nodes, with one sibling access tree<br />action: copy the access tree to both locations, remove additionalMetadata</p>
<p>4.2.3 two (or more) additonalMetadata/describes<br />4.2.3.1 references a distribution node<br />action: remove the <describes>, copy the access tree to the referenced node<br />4.2.3.2 references some other non-recognized node<br />action: leave the <describes>, <br /> additionalMetadata/access -> additionalMetadata/metadata/access</p>
<p>4.3. one additionalMetadata/describes element pointing to a recognized node, <br />with multiple sibling access trees (in eml 2.0.x, these will need to have been wrapped in another element in order to be valid)<br />action: move nothing. can't deal with elements that arent 2.0.1 [aside: addtionalMetadata section will have <metadata> tag added per item 2. above ]</p>
<p>4.4 the eml-author created access trees in additionalMetadata that contain non-eml material. we cannot move these to other parts of the EML instance document. [aside: If metacat has encountered additional not-eml elements alongside access elements, it would have ignored them.]</p>
<p>To be sure output is valid EML, a script should include the parser to check the doc against the schema. Can the stylesheet do this alone? Jing and margaret not sure.</p>
<p>4.1. assuming stylesheet finds the non-eml material (ie, it can parse), possible actions include: <br /> a? ignore access tree, but wrap it in <metadata> </metadata><br /> or b? reject document, tell use that the resulting eml will be invalid<br /> or c? rebuild access tree in the new location (ie, try to interpret what author wanted)</p> Bug #3501 (New): consider adding a datum to boundingAltitudeshttps://projects.ecoinformatics.org/ecoinfo/issues/35012008-09-30T22:55:38ZMargaret O'Brienmob@msi.ucsb.edu
<p>bug added to split this issue from the another bug (<a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: altitudeUnits in geographicCoverage should use eml-unitDictionary definitions (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/1019">#1019</a>) which will be resolved. Possibly, boundingAltitudes should have a datum attached. Alternatively, this level of detail belongs in spatialReference, not geographicCoverage. Before this bug can be addressed, we need to determine who uses this element, and for what purpose.</p> Bug #3499 (New): attribute BoundsGroup may be retyped in a future schema-1.1https://projects.ecoinformatics.org/ecoinfo/issues/34992008-09-30T21:33:50ZMargaret O'Brienmob@msi.ucsb.edu
<p>Resolution of bug <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: Base datatypes in eml-attribute BoundsGroup preclude scientific notation (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/2272">#2272</a> will be to retype boundsGroup's limits to xs:float. <br />However, schema-1.1 may include a new data type which will have features of both float and decimal, called xs:precisionDecimal. see bug <a class="issue tracker-1 status-3 priority-5 priority-highest closed" title="Bug: Base datatypes in eml-attribute BoundsGroup preclude scientific notation (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/2272">#2272</a> or links below:</p>
<p><a class="external" href="http://www.w3.org/TR/xmlschema11-2/#precisionDecimal">http://www.w3.org/TR/xmlschema11-2/#precisionDecimal</a><br /><a class="external" href="http://www.w3.org/XML/2007/dc.pd.html">http://www.w3.org/XML/2007/dc.pd.html</a> (and its references)<br /><a class="external" href="http://754r.ucbtest.org/">http://754r.ucbtest.org/</a></p> Bug #3465 (New): Change InlineType to CDATAhttps://projects.ecoinformatics.org/ecoinfo/issues/34652008-07-28T19:10:12ZJing Taotao@nceas.ucsb.edu
<p>Currently in eml definition, the InlineType, which is the data type of element inline, is PCDATA. This means xml parser will parse it. This causes some problems. For example, SAX parse in Metacat will change "<", if it is in element inline, to "<" during the parsing. This change will make the document invalid. If we change InlineType to CDATA, SAX parser will skip the content in element inline, the problem will be gone.</p> Bug #2758 (New): datamanager does not respect precision on nominal day attributeshttps://projects.ecoinformatics.org/ecoinfo/issues/27582007-02-05T20:46:36ZChad Burtcburt@msi.ucsb.edu
<p>When importing a data table with many floats set to a precision of 0.0001 and a unit of nominal day, the library was rounding to 1 or 3 decimal places.</p>
<p>The affected attributes were matlab_datenum, and Decimal time<br />The dataset was : knb-lter-sbc.2003.2 :: arroyoburro_mooring_arb.txt</p> Bug #2576 (In Progress): Data Manager Library: Database Connection Poolinghttps://projects.ecoinformatics.org/ecoinfo/issues/25762006-10-27T20:11:08ZDuane Costadcosta@lternet.edu
<p>Rework the design and implementation of database connection pooling in the Data Manager Library. Provide a callback mechanism for the calling application to manage its own connection pool. This should include a mechanism for returning a "Connection not available" status to the Data Manager so that it will know that it needs to wait until a connection is available. The Data Manager should generally use one connection per operation, though if the operation has several steps it could re-use the same connection in more than one step if it's safe to do so.</p> Bug #2573 (In Progress): Data manager library need to handle binary data file formathttps://projects.ecoinformatics.org/ecoinfo/issues/25732006-10-27T17:54:02ZJing Taotao@nceas.ucsb.edu
<p>Currently data manager library can load text data, both simple delimited and complicated text format(e.g, fixed width), into relational database. We want a new feature - this library can handle binary data file format (e.g. excel) too.</p> Bug #2125 (New): Cannot define SOM map projection in spatialRaster element of EML2.0.1https://projects.ecoinformatics.org/ecoinfo/issues/21252005-06-14T19:42:06ZMark Servillaservilla@lternet.edu
<p>I am having trouble defining the Space Oblique Mercator map projection<br />in the spatialRaster subtree of EML. The problem is unique to the SOM<br />(any oblique map projection, for that matter) projection - the SOM does<br />not use a prime meridian in the usual sense (i.e., it is fixed to the<br />flight path of the Landsat satellite, not a geographic coordinate system).<br />Since EML requires the primeMeridian-longitude and unit-name attributes<br />to be strictly defined, the document will not validate. Is there a<br />recommendation from the EML community for how to deal with this issue,<br />perhaps making the aforementioned attributes optional?</p>
<p>I have included below an example of how I would define this projection.</p>
<p>Notes:<br />1. The SOM projection does not appear to be common in the remote<br />sensing world other than EOSAT/Landsat/IRS formats. Unfortunately, we have<br />much data in this projection.<br />2. FGDC has a separate element for this projection in their schema.<br />Actually, FGDC has a separate element for each major projection definition.</p>
<p><spatialReference><br /> <horizCoordSysDef name="SOM"><br /> <projCoordSys><br /> <geogCoordSys><br /> <datum/><br /> <spheroid name="International_1909" semiAxisMajor="6378388" <br />denomFlatRatio="0.996633"/><br /> <primeMeridian longitude=""/><br /> <unit name=""><br /> </geogCoordSys><br /> <projection><br /> <parameter name="Landsat_Number" value="5"/><br /> <parameter name="Landsat_Path" value="36"/><br /> <parameter name="False_Easting" value="0"/><br /> <parameter name="False_Northing" value="0"/><br /> <unit name="meter"><br /> </projection><br /> </projCoordSys><br /> </horizCoordSysDef><br /></spatialReference></p> Bug #2085 (New): Access Control not shown by EML stylesheetshttps://projects.ecoinformatics.org/ecoinfo/issues/20852005-05-21T01:35:04ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>The access control information is not shown by XSLTs if no public read access <br />is specified. So if we have access control as:<br /><access> <br /> <allow> <br /> <principal>public</principal><br /> <permission>read</permission><br /> </allow><br /> <allow> <br /> <principal>uid=sgarg,o=NCEAS,dc=ecoinformatics,dc=org</principal><br /> <permission>read</permission><br /> </allow><br /></access></p>
<p>or</p>
<p><access> <br /> <deny> <br /> <principal>public</principal><br /> <permission>read</permission><br /> </deny><br /> <allow> <br /> <principal>uid=sgarg,o=NCEAS,dc=ecoinformatics,dc=org</principal><br /> <permission>read</permission><br /> </allow><br /></access></p>
<p>then the XSLTs will show access rule for uid=sgarg</p>
<p>But if we have this:<br /><access> <br /> <allow> <br /> <principal>uid=sgarg,o=NCEAS,dc=ecoinformatics,dc=org</principal><br /> <permission>read</permission><br /> </allow><br /></access></p>
<p>then nothing is shown by XSLTs.</p> Bug #2076 (New): containers for eml-literature docshttps://projects.ecoinformatics.org/ecoinfo/issues/20762005-05-03T18:49:45ZMargaret O'Brienmob@msi.ucsb.edu
<p>SBC-LTER has been investigating using EML and Metacat for our site's<br />bibliography. In creating and displaying my xml, I've come up with a list of<br />potential changes to the eml-literature schema, which dont affect the validation<br />of current citation eml docs. At the network office, James Brunt and Mark<br />Servilla are also pursuing something similar while constructing the network's<br />litdb, and will have some input soon.</p>
<p>My goal was to create a hanging-paragraph style display of our site's<br />bibliography, with links to the paper and to the dataset as appropriate. EML's<br />imports/includes were a bit intimidating, so instead, I chose to start from<br />scratch and write a dtd that looks like eml-literature, but included just the<br />basic tags needed for the typical hanging-paragraph bibliography display. So the<br />dtd is kind of an "eml-lite". But in the long run of course, my wimpy dtd should<br />disappear.</p>
<p>What I've done so far: Create a test xml doc of several pubs with this dtd. The<br />citations are mostly fictional to suit my stylesheet testing needs. I created a<br />stylesheet to display it in a typical hanging-paragraph list, filtered by type,<br />then sorted by year and author. Looking for some thrills, I went ahead and<br />inserted it into metacat, and mapped the stylesheet (with help from Sid). This<br />seemed to be a good way to show what I had in mind (not to mention, see <br />if it really worked). Since most of the citations were created for testing the<br />stylesheet, most of the url links really dont go anywhere. It was the general<br />format that I was interested in. You can see the results at:<br /><a class="external" href="http://sbc.lternet.edu/catalog/metacat?action=read&qformat=sbclter&docid=sbc_pubs_test.1.1">http://sbc.lternet.edu/catalog/metacat?action=read&qformat=sbclter&docid=sbc_pubs_test.1.1</a><br />The xml file and stylesheet can be found at:<br /><a class="external" href="http://sbc.lternet.edu/external/EML/SBC_publications/sbcCitationList.xml">http://sbc.lternet.edu/external/EML/SBC_publications/sbcCitationList.xml</a><br /><a class="external" href="http://sbc.lternet.edu/external/EML/SBC_publications/sbcCitationList.xsl">http://sbc.lternet.edu/external/EML/SBC_publications/sbcCitationList.xsl</a></p>
<p>What I haven't done: some cleanup, create css parameters, use id refs, searches,<br />link the title to the existing table-style eml-literature.xsl. I've started on a<br />script to convert SBC's own html list of pubs to xml.</p>
<p>Here is the list of differences between my dtd and the eml-literature schema:<br />1. this dtd has a <citationList> as the root element, (eml: no such tag)<br />2. <citation> is child of citationList, 1 to many allowed. (eml: one only, root<br />element)<br />OK, these 2 do affect current docs, unless they are put into another module<br />(eml-publications?) that uses eml-literature. Having all the citations in one<br />list is much easier to maintain than the current scheme of 1-citation-per-doc.<br />Also, a research site is likely to have many repeated authors, and if the pubs<br />are in one list, authors can be maintained in the additionalMetadata, and<br />linked with ids.</p>
<p>3. <title> is allowed to have children, mainly so species binomials can be<br />italicized. Changing <title> from type:string to type:text would take care of<br />this (?without affecting current string content?)</p>
<p>4. journal, volume, pageRange are 0 or 1, to accomodate in_press/submitted<br />papers. <pubDate> is already optional. My stylesheet used the absence of a<br />pubDate to filter out the in-press pubs. Citations may spend only a short time<br />in this state, but it's very important to scientists to make their newest papers<br />available quickly.</p>
<p>5. added an optional <contact> tree, since the first author is not always the<br />person to contact for reprints. The stylesheet looks here first, then at the<br />list of creators.</p>
<p>6. added an optional <datasetId> so an accompanying archived data package can be<br />recorded. This is debatable. I was looking for a way to link archived datasets<br />to the citation, since some journals are requesting that data be published along<br />with papers. It seemed a better idea to start from the citation and link back to<br />the dataset(s), rather than including the finished paper's citation with the<br />dataset metadata, since after a dataset is revised, the paper may belong only<br />with an earlier version. Also, papers are likely to use data from multiple<br />datasets. I was partial to the datasetId tag because the rest of the url could<br />be created with stylesheet variables. However, this method doesnt allow urls for<br />any other data catalogs to be included (unless you made additional variables).<br />Chris suggested an alternative - to use a <distribution type="information"> tree<br />for the dataset. I'm not sure that this is specific enough.</p>
<p>7. added an optional <description> to distribution/online. Actually, I've wished<br />for this (or something like it) in eml-dataset, too. It provides a place to put<br />some text which can appear inside the anchor tags in the html. Which would<br />really help if the dataset link was put here, to avoid having to diplay the ugly<br />url and instead describe where the link actually goes. But maybe there's already<br />a mechanism for this that I've missed.</p>
<p>Thanks-<br />Margaret (sbc-lter IM)</p> Bug #1991 (In Progress): add fields for information about metadata maintenancehttps://projects.ecoinformatics.org/ecoinfo/issues/19912005-02-28T21:06:24ZMatt Jonesjones@nceas.ucsb.edu
<p>This is a request for additional fields regarding metadata maintenance that I am<br />filing for Xiaoping Wang.</p>
<p>----- Original request from Xiaoping Wang -----------<br />Dear eml-dev:</p>
<p>As mentioned in my email to Matt and Peter (see below), providing necessary<br />timestamp inforamtion for the EML metadata document is important not only to<br />metadata generators but also to metadata users. Both<br />/eml/dataset/maintenance/description and<br />/eml/dataset/maintenance/maintenanceUpdateFrequency in EML schemas are used for<br />description of dataset, not for the metadata document itself. Although we can<br />use /eml/additionalMetadata to say something about the metadata document, I<br />believe that the timestamp information about the EML metadata document is so<br />important that it needs to be highlighted. The following is my recommendataion<br />about the way you can provide more information about the metadata itself.</p>
<p>In the /eml/dataset/res:ResourceGroup, instead of using metadataProvider as one<br />of the elements, use metadataInformation as suggested below:<br /><metadataInformation><br /> A sequency of<br /> <metadataProvider> required (comment: inforamtion<br />about metadata providers is listed here)<br /> <metadataCreationDate> required (comment: the date when<br />the metadata document is originally created)<br /> <metadateMaintenance> Optional (comment: this element is<br />used when the metadata document needs to be updated in the future)<br /> A sequency of<br /> <lastUpdateDate> required (comment: the date of last<br />metadata update)<br /> <oldVule> required (comment: for example, the<br />endDate for rangeOfDates, numberOfRecords for an entity (table), size of entity<br />(table)........ These values will be changed after new data are loaded into the<br />dataset)<br /> <updateFrequence> required (comment: by comapring<br />updateFrequency and lastUpdateDate, metadata developers know when they need to<br />update their metadata document, and metadata users know if the metadata document<br />describes the most current information about the dataset)</p>
<p>These are the necessary elements that I think they should be provided in EML<br />metadata document. Hope my recommendation helps.</p>
<p>Thank you very much for your support.</p>
<p>Xiaoping Wang<br />PMEL /NOAA</p>
<p>---------- End request ----------<br />The full email thread regarding this request can be seen in the EML-dev email<br />archive here:<br /><a class="external" href="http://www.ecoinformatics.org/pipermail/eml-dev/2005-February/001076.html">http://www.ecoinformatics.org/pipermail/eml-dev/2005-February/001076.html</a></p> Bug #501 (New): change in documentation structurehttps://projects.ecoinformatics.org/ecoinfo/issues/5012002-05-09T16:11:17ZChad Berkleyberkley@nceas.ucsb.edu
<p>We should change the structure of the documentation xsd so that each of the<br />documentation tags (summary, tooltip and description) are inlined into one bit<br />of text instead of sibling elements. The new documentation should look<br />something like</p>
<p><description><summary>The <tooltip>title field</tooltip> is used to generally<br />describe the resource.</summary> It is typically 15 to 20 words long, and<br />provides a concise yet thorough descrition of the resource.</documentation></p>