[eml-dev] [Bug 3445] New: - stmml.xsd non-deterministic

[inigo]

> im not sure whether stmml schema bugs ought to be reported in eml's 
> bugzilla.
>
> i would say that the stmml developers would be more efficient, 

i meant to say that reporting this bug to the stmml dev. 
group/individuals would be most efficient.

also, this affects EML docs when we use "custom units", and follow the 
'stmml' schema guidance
for reporting those.  even though it is advisable to 'call up' the stmml 
schema in the 'additionalMetadata'
section, in practice, many LTER documents follow the stmml schema rules 
to report the
so called custom units without a explicit call/reference to stmml.  when 
we do that, we avoid the
editor complaints about the stmml (we've seen those complaints since 2005)

perhaps eml should consider moving away from the current dichotomy 
standarUnits/customUnits
into another solution. 

in any case, beyond the realm of EML -the subject -units- - is worth of 
careful study, as there
is potential to undermine the data integration capabilities by creating  
units that hardly can be
categorized as units.  currently Todd Ackerman (Niwot Ridge IM)  is 
leading efforts at LTER to
address some of these issues. There is a mailing list, a working group 
and a need to move this
forward. The unit issue represents a clear obstacle in the path to data 
integration. Not that EML
in its present form can do much about it, but we may.

cheers, inigo

> bugzilla-daemon at ecoinformatics.org wrote:
>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3445
>>
>>            Summary: stmml.xsd non-deterministic
>>            Product: EML
>>            Version: 2.0.1
>>           Platform: Other
>>         OS/Version: All
>>             Status: NEW
>>           Severity: normal
>>           Priority: P2
>>          Component: eml - general bugs
>>         AssignedTo: jones at nceas.ucsb.edu
>>         ReportedBy: mob at icess.ucsb.edu
>>          QAContact: eml-dev at ecoinformatics.org
>>
>>
>> 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).
>>
>> This bug is very similar to 2054 -- that plagued EML for so long.
>>
>> Here is the offending snip from stmml.xsd, starting at line 1708. The 
>> problem
>> is the unbounded "definition" right next to the <xs:choice>
>>
>> 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.
>>     <xsd:sequence>
>>         <xsd:element ref="definition" minOccurs="0"/>         
>> <xsd:choice minOccurs="0" maxOccurs="unbounded">
>>           <xsd:element ref="alternative"/>
>>           <xsd:element ref="annotation"/>
>>           <xsd:element ref="definition"/>
>>           <xsd:element ref="description"/>
>>           <xsd:element ref="enumeration"/>
>>           <xsd:element ref="relatedEntry"/>
>>         </xsd:choice>
>>       </xsd:sequence>
>> _______________________________________________
>> Eml-dev mailing list
>> Eml-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>   
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev