EML: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362012-11-14T18:21:18ZEcoinformatics Redmine
Redmine Bug #5734 (Resolved): Attribute Domain info not rendered by stylesheetshttps://projects.ecoinformatics.org/ecoinfo/issues/57342012-11-14T18:21:18Zben leinfelderleinfelder@nceas.ucsb.edu
<p>For example.</p>
<p><a class="external" href="http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=default&sessionid=0&docid=nceas.997.2&displaymodule=attributedomain&entitytype=dataTable&entityindex=1&attributeindex=1">http://knb.ecoinformatics.org/knb/metacat?action=read&qformat=default&sessionid=0&docid=nceas.997.2&displaymodule=attributedomain&entitytype=dataTable&entityindex=1&attributeindex=1</a></p> Bug #5705 (Resolved): Contact showing multiple people/orgs when EML file does nothttps://projects.ecoinformatics.org/ecoinfo/issues/57052012-09-06T22:03:22Zben leinfelderleinfelder@nceas.ucsb.edu
<p>When styling in Metacat (and presumably elsewhere) we see many entries in contact that don't make much sense.<br />see examples:<br />nceas.973<br />nceas.931.8</p> Bug #3836 (Resolved): runEMLParser script should include saxvalidatehttps://projects.ecoinformatics.org/ecoinfo/issues/38362009-02-24T20:49:32ZMargaret O'Brienmob@msi.ucsb.edu
<p>a script is located in the /lib/ called runEMLParser which runs a java class to check references and IDs in instance documents. It does not check the document against the schema (SAXValidate). The online emlparser and the unit tests run both, and the parser script would be more useful if it also ran both. It should only validate against the schema in it's parent directory, so in eml 2.1, you would only be able to validate 2.1 instances.</p> Bug #3688 (Resolved): documentation to be fixedhttps://projects.ecoinformatics.org/ecoinfo/issues/36882008-11-24T16:49:06ZMargaret O'Brienmob@msi.ucsb.edu
<p>there is now a separate page for the changes in EML2.1. It should be linked from the index.html page somehow</p> Bug #3600 (Resolved): recreate all the PNG fileshttps://projects.ecoinformatics.org/ecoinfo/issues/36002008-11-06T18:26:35ZMargaret O'Brienmob@msi.ucsb.edu
<p>Two 2.1 upgrades in particular:<br />1. method ->methods, and datetime ->dateTime<br />2. retyping geographicCoverage elements<br />affected almost all the schemas. The best solution is to recreate all the PNG files with xmlspy. very tedious, sorry. Use the existing online images as templates to be sure that expansion of complex types is consistent.</p>
<p>changes to "methods" affects:<br />dataTable<br />entity<br />spatialRaster<br />spatialVector<br />storedProcedure<br />view</p> Bug #3599 (Resolved): finish documentation in eml-physical.xsdhttps://projects.ecoinformatics.org/ecoinfo/issues/35992008-11-06T18:10:05ZMargaret O'Brienmob@msi.ucsb.edu
<p>the only thing left in eml-physical is to clarify the documentation of the new type. by creating this new p3 bug, I can close several others where the schema changes are done.</p> Bug #3594 (Resolved): tests only validate documents in test dir against SAX not EMLhttps://projects.ecoinformatics.org/ecoinfo/issues/35942008-11-05T21:25:08ZShaun Walbridgewalbridge@nceas.ucsb.edu
<p>EML files residing within the test/ folder should be tested for EML validity along with SAX validation, to keep in line with how the emlparser servlet validates documents. Files known to be bad should reside within test/invalidEML/ folder, leaving only valid EML within the base test/ folder.</p> Bug #3553 (Resolved): Create a schema file whose content is the definition of unit typeshttps://projects.ecoinformatics.org/ecoinfo/issues/35532008-10-22T20:54:52ZMargaret O'Brienmob@msi.ucsb.edu
<p>This item needs its own bug so that it can be referenced as changes are needed. It was precipitated by the fix for 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>.</p>
<p>In EML 201, the unit dictionaries are enumerated lists that are defined ad hoc in individual modules. For example, attribute.xsd defined a StandardUnitType, and spatialRaster defines types called lengthUnits and angleUnits. These types should be defined altogether in a separate schema doc (eml-unitTypeDefinitions.xsd), which can be imported as needed. The simplest organization would be to create enumerated lists based on unitTypes, and then combine these into larger groups with xs:union:</p>
<p><xs:simpleType name="StandardUnitDictionaryType"><br /><xs:union memberTypes="unit:LengthUnitDictionaryType unit:OtherUnitDictionaryType "/><br /></xs:simpleType></p>
<p><xs:simpleType name="LengthUnitDictionaryType"><br /> <xs:restriction base="xs:string"><br /> <xs:enumeration value="meter"/><br /> <xs:enumeration value="nanometer"/><br /> ...etc<br /> </xs:restriction><br /></xs:simpleType></p>
<p><xs:simpleType name="OtherUnitDictionaryType"><br /> <xs:restriction base="xs:string"><br /> <!-- all the other units that were in the standard list enumeration --><br /> ...<br /> </xs:restriction><br /></xs:simpleType></p>
<p>Initially, eml-unitTypeDefinitions.xsd needs to contain just these two types, which are used by attribute.xsd (standardUnits), and by coverage.xsd (lengthUnits). Additional Types can be expected for types currently defined in the spatial schemas (e.g., angle) as those schemas are revisited in the future. Types could be added as necessary -- such as for information units, which are allowable under SI, but not currently included in our dictionary (<xs:simpleType name="InformationUnitDictionary"> )</p>
<p>This is the first step (albeit, a tiny one) toward uncoupling units from the EML spec. It appears that an effort was started once before to create these enumerations: a transformation stylesheet exists to create enumeration lists from the standardDictionary.xml file, but it was never finished. See "getunits.xsl". Generating the schema doc by transforming the unitDictionary.xml would be one way to keep the dictionary and the enumerations synchronized.</p> Bug #3541 (Resolved): clarify documentation on polygons and grings, indicate relationship to FGDChttps://projects.ecoinformatics.org/ecoinfo/issues/35412008-10-21T17:34:38ZMargaret O'Brienmob@msi.ucsb.edu
<p>The documentation in this section is sparse. The NEON project is currently evaluating EML, and has pointed out a discrepancy between FGDC and EML which should be either explained or the 2 specifications should agree.</p>
<p>FGDC: types that are equivalent to "datasetGPolygonOuterGRing" and "datasetGPolygonExclusionGRing" require a minimum of 4 points for polygons<br />EML: a) datasetGPolygonOuterGRing: requires 3 minimum, and b) datasetGPolygonExclusionGRing requires 1.<br />Reasoning: a) FGDC documentation states that a polygon needs to have 4 points, and the first and last should be identical. However, XMLSchema does not have a way to enforce this. So EML requires only 3, and the 4th is implied.<br />b) allowing the exclusionRing to have only one point means that a single point can be excluded, presumably, a single station.</p>
<p>EML's documentation for datasetGPolygonOuterGRing should make this clear. It also could recommend that xsl stylesheets that transform EML to FGDC should repeat the first lat/lon pair as the last when creating a list of points.</p>
<p>the alternative to both datasetGPolygonOuterGRing and datasetGPolygonExclusionGRing is gRingType, which is a string of ordered pairs. Presumably, this was supposed to be a field that could be directly translated to FGDC. If so, the documentation should state this, and recommended that a minimum of 4 pairs be included. However, if this field remains an unrestricted string, this is not enforceable with xmlschema.</p> Bug #3500 (Resolved): restrict content of boundingCoordinates, gRingLat and Long to lat and lon r...https://projects.ecoinformatics.org/ecoinfo/issues/35002008-09-30T21:46:09ZMargaret O'Brienmob@msi.ucsb.edu
<p>Currently, the boundingCoordinates in the GeographicCoverage Type (e.g., westBoundingCoordinate, etc) are of type xs:string. The content of these elements should be restricted to reasonable latitude and longitude values, e.g.,<br />lons: -180<x<180 and lats -90<x<90, inclusive.</p>
<p><appinfo> should be updated as appropriate.</p>
<p><xs:element name="westBoundingCoordinate" type="xs:decimal"><br /> <xs:simpleType> <br /> <xs:restriction base="xs:decimal"><br /> <xs:minInclusive value="-180"/><br /> <xs:maxInclusive value="180"/><br /> </xs:restriction><br /> </xs:simpleType> <br /></element></p> Bug #3491 (Resolved): stylesheet fix for eml-physical.xsl, byte unitshttps://projects.ecoinformatics.org/ecoinfo/issues/34912008-09-22T15:19:44ZMargaret O'Brienmob@msi.ucsb.edu
<p>From IRC, shaun:<br />minor EML fix request: add 's' after <xsl:value-of select="./@unit"/> in eml-physical.xsl<br />the unit type is the singular, but should be pluralized to avoid '15990 byte'</p> Bug #3490 (Resolved): update documentation for givenName, surNamehttps://projects.ecoinformatics.org/ecoinfo/issues/34902008-09-22T15:17:45ZMargaret O'Brienmob@msi.ucsb.edu
<p>the appinfo and examples for these elements are sparse. add more info for authors to place names correctly.</p> Bug #3480 (Resolved): duplicate distribution types (in resource.xsd, and physical.xsd)https://projects.ecoinformatics.org/ecoinfo/issues/34802008-08-29T18:08:43ZMargaret O'Brienmob@msi.ucsb.edu
<p>In examining <distribution>: there are currently 2 Distribution Types, which are identical:</p>
<p>1. eml-physical.xsd: <xs:complexType name="PhysicalDistributionType"></p>
<p>used by:<br />eml-physical.xsd:1169: <xs:element name="distribution" type="PhysicalDistributionType"</p>
<p>and <br />2. eml-resource.xsd: <xs:complexType name="DistributionType"></p>
<p>used in these schemas:<br />eml-resource.xsd:364: <xs:element name="distribution" type="DistributionType" minOccurs="0" maxOccurs="unbounded"><br />eml-software.xsd:129: <xs:element name="distribution" type="res:DistributionType" maxOccurs="unbounded"> (this one is a child of <implementation>)</p>
<p>I cant tell why this is the case. What was the rationale for having 2?</p>
<p>Also note that bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: All children of required "offline" element are optional in PhysicalDistributionType (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/1154">#1154</a> only mentions one of these, PhysicalDistributionType</p> Bug #3448 (Resolved): stmml.xsd non-deterministichttps://projects.ecoinformatics.org/ecoinfo/issues/34482008-07-11T15:43:28ZMargaret O'Brienmob@msi.ucsb.edu
<p>A section of stmml.xsd is invalid, according to a new parser feature that Jing just added in response to bug 3232, and also to the venerable parsers in xmlSpy and oxygen. Interestingly, the 2 commercial editors don't catch up the error unless the schema is loaded directly, instead of imported (ie, by attribute.xsd).</p>
<p>This bug is very similar to 2054 -- that plagued EML for so long.</p>
<p>Here is the offending snip from stmml.xsd, starting at line 1708. The problem is the unbounded "definition" right next to the <xs:choice></p>
<p>It appears that the invalidity can be fixed by either removing the minOccurs (ie, making it required) or by removing the <element ref="definition" ...> altogether. The sequence followed by choice structure makes any combination of elements ok, so this declaration seems to be extra. I do not see a more recent stmml.xsd available (cml.sourceforge.org). And we shouldn't go trekking of with our own flavor of stmml, so awaiting recommendations. </p>
<pre><code>&lt;xsd:sequence&gt;<br /> &lt;xsd:element ref="definition" minOccurs="0"/&gt; <br /> &lt;xsd:choice minOccurs="0" maxOccurs="unbounded"&gt;<br /> &lt;xsd:element ref="alternative"/&gt;<br /> &lt;xsd:element ref="annotation"/&gt;<br /> &lt;xsd:element ref="definition"/&gt;<br /> &lt;xsd:element ref="description"/&gt;<br /> &lt;xsd:element ref="enumeration"/&gt;<br /> &lt;xsd:element ref="relatedEntry"/&gt;<br /> &lt;/xsd:choice&gt;<br /> &lt;/xsd:sequence&gt;</code></pre> Bug #3445 (Resolved): stmml.xsd non-deterministichttps://projects.ecoinformatics.org/ecoinfo/issues/34452008-07-10T23:37:19ZMargaret O'Brienmob@msi.ucsb.edu
<p>A section of stmml.xsd is invalid, according to a new parser feature that Jing just added in response to bug 3232, and also to the venerable parsers in xmlSpy and oxygen. Interestingly, the 2 commercial editors don't catch up the error unless the schema is loaded directly, instead of imported (ie, by attribute.xsd).</p>
<p>This bug is very similar to 2054 -- that plagued EML for so long.</p>
<p>Here is the offending snip from stmml.xsd, starting at line 1708. The problem is the unbounded "definition" right next to the <xs:choice></p>
<p>It appears that the invalidity can be fixed by either removing the minOccurs (ie, making it required) or by removing the <element ref="definition" ...> altogether. The sequence followed by choice structure makes any combination of elements ok, so this declaration seems to be extra. I do not see a more recent stmml.xsd available (cml.sourceforge.org). And we shouldn't go trekking of with our own flavor of stmml, so awaiting recommendations. </p>
<pre><code>&lt;xsd:sequence&gt;<br /> &lt;xsd:element ref="definition" minOccurs="0"/&gt; <br /> &lt;xsd:choice minOccurs="0" maxOccurs="unbounded"&gt;<br /> &lt;xsd:element ref="alternative"/&gt;<br /> &lt;xsd:element ref="annotation"/&gt;<br /> &lt;xsd:element ref="definition"/&gt;<br /> &lt;xsd:element ref="description"/&gt;<br /> &lt;xsd:element ref="enumeration"/&gt;<br /> &lt;xsd:element ref="relatedEntry"/&gt;<br /> &lt;/xsd:choice&gt;<br /> &lt;/xsd:sequence&gt;</code></pre>