EML: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362002-10-17T18:50:12ZEcoinformatics Redmine
Redmine Bug #632 (Resolved): broken link in faqhttps://projects.ecoinformatics.org/ecoinfo/issues/6322002-10-17T18:50:12ZChad Berkleyberkley@nceas.ucsb.edu
<p>There is a broken link in the FAQ. It is in item 4 "formal specification" and<br />it should be linked to /software/eml/eml-2.0.0rc2/index.html but instead it is<br />linked to /software/eml/eml-2.0.0rc2/eml-docbook.html.</p> Bug #629 (Resolved): unit conversion coefficients need checkinghttps://projects.ecoinformatics.org/ecoinfo/issues/6292002-10-14T20:52:09ZChad Berkleyberkley@nceas.ucsb.edu
<p>The multipliers in the eml-unitDictionary.xml file need to be checked for each<br />unit in the file. There is also one unit, nanomolesPerGramPerSecond, that does<br />not have a multiplier but needs to have one.</p> Bug #598 (Resolved): literature namespace references are inconsistenthttps://projects.ecoinformatics.org/ecoinfo/issues/5982002-09-20T14:28:30ZChad Berkleyberkley@nceas.ucsb.edu
<p>need to change the namespace prefixes for literature. some of them are cit <br />and others are lit.</p> Bug #579 (Resolved): eml-docbook.xml doesn't validatehttps://projects.ecoinformatics.org/ecoinfo/issues/5792002-08-29T18:42:45ZDavid Blankmandblankman@lternet.edu
<p>The docbook eml-docbook.xml produced by running ant docbook does not validate.</p> Bug #567 (Resolved): create a sample EML2.0 instance documenthttps://projects.ecoinformatics.org/ecoinfo/issues/5672002-08-22T15:11:19ZChad Berkleyberkley@nceas.ucsb.edu
<p>In the 8/21/02 conference call, it was agreed that Chad and Peter would create a<br />sample instance document of EML that encompassed as many features of EML as<br />possible. This document would be a sort of reference implementation for others<br />to look at. It will be distributed with eml2.0.</p> Bug #556 (Resolved): change namespaces to include ecoinformatics.orghttps://projects.ecoinformatics.org/ecoinfo/issues/5562002-08-07T15:53:38ZChad Berkleyberkley@nceas.ucsb.edu
<p>We need to change the namespaces in EML 2 to inlcude the text <br />'ecoinformatics.org'. This will ensure uniqueness.</p> Bug #544 (Resolved): issues about storageType and attributeDomainhttps://projects.ecoinformatics.org/ecoinfo/issues/5442002-07-05T18:59:57ZDan Higginshiggins@nceas.ucsb.edu
<p>The beta9 version of the attribute module has an element called <br />"storageType". As I understand it, the preferred use of this attribute is to<br />contain the XMLSchema datatype of the attribute (e.g. 'string'). The attribute<br />module also has a subtree named 'attributeDomain' with the three branches<br />'enumeratedDomain', 'textDomain', and 'numericDomain'.<br /> It seems to me that the "storageType" and "attributeDomain" elements are<br />logically related, but that relation is not indicated in the attribute module.<br />As an example, consider a storageType of 'string'. With XMLSchema datatypes, the<br />concept of a datatype is limited using "facets". Thus a string can be further<br />restricted using (for example) 'enumeration', 'maxLength, or 'pattern'<br />constraining facets. Similarly, 'totalDigits' or other facets can be used to<br />contrain a "decimal" datatype.<br /> In the 'attribute' module of eml, however, such contraints are put into the<br />'attributeDomain' subtree. The 'enumeratedDomain' subelement does have the<br />ability to enter code values and the associated definition (a code/definition<br />facet is NOT available in XMLSchema datatypes), but the 'enumeratedDomain'<br />subelement does NOT have a simple enumeration where one just lists allowed<br />values for an attribute.</p>
<pre><code>In summary, I would suggest that the enumeratedDomain element should have a<br />simple 'enumeration' child with the ability to just list allowed values (and not<br />require definitions), and/or we should combine the 'storageType' and<br />'attributeDomain' elements into something like the structure used with XMLSchema<br />datatypes and contraining 'facets'/</code></pre> Bug #498 (Resolved): check root element names for consistencyhttps://projects.ecoinformatics.org/ecoinfo/issues/4982002-05-02T01:11:08ZMatt Jonesjones@nceas.ucsb.edu
<p>Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:</p>
<p>1) check root element names for all modules to be sure they are consistent. <br />Some now use an "eml-" prefix, others don't. My notes from the meeting indicate<br />that we should make the root elements all camel caps, and get rid of the "eml-" <br />prefix (although the file names would keep the prefix). I'm not positive that I<br />go tthis right, though. Opinions?</p> Bug #484 (Resolved): eml-attribute changes neededhttps://projects.ecoinformatics.org/ecoinfo/issues/4842002-05-01T23:52:07ZMatt Jonesjones@nceas.ucsb.edu
<p>Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:<br />Responsible: Chad, Dan, David</p>
<p>1) rename dataType to storageType -- minimally suggest use fo XML Schema DT as<br />base for storageType, add attribute "typeSystem" for referencing the system used<br />2) add "unitSystem" attribute to w/ default of STMML, make "unit" required with<br />default of "dimensionless" <br />3) add measurementScale element for documenting scale (ordinal, ratio, interval,<br />nominal). We discussed whether this was implied by dataType/unit, but decided to<br />add it, even though it probably is somehow implied by the dimension of the<br />measurement<br />4) add "accuracy" element, use FGDC "dataQuality" model for it<br />5) how do we express precision & accuracy -- need to be explicit in our field<br />documentation<br />6) generally resolve the storageType/dimension/unit/measurementScale morass<br />7) add explanation/reason field to the "missingValueCode" so that people can<br />explain what "-9999" means in their data set<br />8) move "textDomain" and "enumeratedDomain" up so that they are siblings of<br />numeric domain, remove the choice<br />9) add "enforced" attribute to enumeratedDomain element with allowable values<br />"yes", "no", defaults to "yes" <br />10) enumeratedDomain: need externally referenced codeset, reference to dataTable<br />entity that contains codes (2 columns). below is a content model from my notes<br />that doesn't make a lot of sense to me right now. Corinna says that the sequence<br />after enumeratedDomain should be optional,repeatable<br /> enumeratedDomain
|- list
| |- code
| |- def
| |- source
|
|- entity
| |- entityID
| |- codeColumn
| |- codeDefinitionColumn
|
|- externalSource</p> Bug #483 (Resolved): eml-entity changes neededhttps://projects.ecoinformatics.org/ecoinfo/issues/4832002-05-01T23:36:32ZMatt Jonesjones@nceas.ucsb.edu
<p>Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:<br />Responsible: Chad, Peter</p>
<p>0) name all entity types using camel caps (e.g., dataTable)<br />1) otherEntity stays in eml-entity module, others separate modules<br />2) entity types are: otherEntity, dataTable, dataView, StoredProcedure,<br />spatialImage, spatialGrid, spatialVector<br />3) expand names to use long names for all elements, including spatial types<br />4) add "spatialReference" module -- not sure how this will be tied to the other<br />spatial types<br />5) move "spatialRepresentationType" to the spatialRepresentation ComplexType<br />6) Possibly put connection info into the entity description, although I think we<br />decided against this by the end (putting it in resource instead)</p>
<p>Peter's notes include a mention of "change logs" which I don't understand. Peter?</p> Bug #481 (Resolved): eml-party changes neededhttps://projects.ecoinformatics.org/ecoinfo/issues/4812002-05-01T23:20:09ZMatt Jonesjones@nceas.ucsb.edu
<p>Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:<br />Responsible: Chad</p>
<p>1) Remove role from ResponsibleParty, but keep the simple type for use elsewhere<br />2) Review and define the values in the role type -- we may have decided to<br />eliminate these enumerated values and just use a free-text element when needed,<br />but I can't tell from my notes.</p> Bug #470 (Resolved): need to be able to inline data in EMLhttps://projects.ecoinformatics.org/ecoinfo/issues/4702002-04-15T22:47:19ZMatt Jonesjones@nceas.ucsb.edu
<p>Request to be able to inline data in the same file as EML. For binary data,<br />this could be Base64 encoded. For text it could be in stream. Probably should<br />work from a current standard way to do it like XSIL.</p> Bug #450 (Resolved): entityType and formathttps://projects.ecoinformatics.org/ecoinfo/issues/4502002-03-27T18:27:55ZMatt Jonesjones@nceas.ucsb.edu
<p>The eml-entity module has a field called "entityType" that is supposed to<br />contain the type of the entity for "other" entities. The eml-physical file has<br />a field called "format" that is supposed to contain the name of the data forat<br />for the physical file. We need to clarify the difference between these fields.</p>
<p>If one is using a mime-type to indicate the format (e.g., image/gif), where<br />should that go? My guess is eml-physical/format.</p> Bug #443 (Resolved): revise duration elements in eml-accesshttps://projects.ecoinformatics.org/ecoinfo/issues/4432002-03-14T15:17:10ZDan Higginshiggins@nceas.ucsb.edu
<p>eml-access has a duration element that is defined in terms of temporalCoverage.<br />This introduces a number of temporal concepts that are nonsensical when applied<br />to the duration of 'tickets' (e.g. geological time scales). It is suggested that<br />simple start and stop times/dates be used here rather than temporal coverage<br />concepts.</p> Bug #430 (Resolved): need DTDs to correspond to XSD fileshttps://projects.ecoinformatics.org/ecoinfo/issues/4302002-02-15T02:14:28ZMatt Jonesjones@nceas.ucsb.edu
<p>The current set of DTD files checked into the eml module do not correspond in a<br />1:1 way with the XSD files. In particular, 1) parameter entities were resolved<br />(e.g., eml-dataset includes eml-resource) and should not be; and 2) multiple<br />global elements in the schema should be represented as possible root elements in<br />the DTD but in fact were eliminated. For example, in eml-entity, both<br />"table-entity" and "other-entity" should be root elements in the eml-entity.dtd,<br />but infact only "table-entity" is present because it caused some problems<br />withthe software we were using to parse DTDs. This needs to be fixed so that<br />all appropriate elements are available.</p>