EML: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362004-04-22T17:05:31ZEcoinformatics Redmine
Redmine Bug #1529 (Resolved): no tag to specify how to handle mutltiple, repeated delimitershttps://projects.ecoinformatics.org/ecoinfo/issues/15292004-04-22T17:05:31ZDan Higginshiggins@nceas.ucsb.edu
<p>There is nothing in eml to say whether multiple repeated delimiters should be<br />treated as a single delimited. An example is when a space delimiter is used;<br />often there may be several repeated spaces that should be treated a a single<br />delimiter, but not always. Need a boolean to say whether sequential delimiters<br />should be treated as a single delimiter or not.</p>
<p>In Morpho 1.5 this information was placed in addedMetadata.</p> Bug #1233 (Resolved): dateTime formatString Documentation contains incorrect examplehttps://projects.ecoinformatics.org/ecoinfo/issues/12332003-12-09T01:14:21ZMatthew Brookebrooke@nceas.ucsb.edu
<p>dateTime formatString Documentation contains incorrect example:</p>
<p>---------------------<br />Example(s):<br />YYYY-MM-DDTHH:MM:SS<br />---------------------</p>
<p>HH:MM:SS should be lowercase - hh:mm:ss</p> Bug #1136 (Resolved): kelvin conversion incorrect in unit dictionaryhttps://projects.ecoinformatics.org/ecoinfo/issues/11362003-08-23T03:42:25ZMatt Jonesjones@nceas.ucsb.edu
<p>Shawn Bowers reported:</p>
<blockquote>
<p>Hi Matt,</p>
<p>I was testing some prolog code to convert between units, and noticed that <br />the formula to go from Fahrenheit to Kelvin was 5/9 - 17.778. I don't <br />think this is correct.</p>
<p>Shawn</p>
</blockquote> Bug #1031 (Resolved): enumeratedDomain doesn't define value order for ordinalshttps://projects.ecoinformatics.org/ecoinfo/issues/10312003-04-08T20:33:01ZMatt Jonesjones@nceas.ucsb.edu
<p>Ordinal scale measurements have a discrete list of values with a specific<br />ordering of those values. EML does not provide a mechanism for specifying what<br />this order should be. We need to add this feature. Two possible approaches<br />come immediately to mind:</p>
<p>1) Redefine the "ordinal" element to state that values should be listed in the<br />code/definition pairs in ascending order. This has the disadvantage of not<br />being backwards compatible (ie, some eml-2.0.0 documents might not list them in<br />this order, and interpreting them in the context of newer versions of eml will<br />lead to incorrect ordering.</p>
<p>2) add an optional attribute to "codeDefinition" named "order" that is of type<br />long integer, and make its value correspond to the order of the items. For<br />example, for LOW, MEDIUM, HIGH, the order attribute might be "LOW=1, MEDIUM=2,<br />and HIGH=3. This is backwards compatible because it is optional.</p>
<p>I currently see no disadvantages to this approach (2) and so that is what I<br />recommend at this point. Feedback appreciated.</p> Bug #960 (Resolved): parser not correctly parsing <describes> tag in additionalMetadatahttps://projects.ecoinformatics.org/ecoinfo/issues/9602003-01-23T17:19:49ZChad Berkleyberkley@nceas.ucsb.edu
<p>Dan Higgins pointed out to me that the example eml document in lib/sample has a<br />describes tag that points to a dataset tag in the document. the ids appear to<br />be valid but the parser says that the "describes tag must point to a valid element".</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>