[eml-dev] EML 2.1 release coming soon- draft

[inigo]

Dear Matt,

So <describes> (eml:eml/additionalMetadata/describes) is
fundamentally important, you argue. Why is <describes>
optional ?  It is an element barely used in LTER,  and I
don't recall a strong push in LTER best practices for its use.
(Then again, by the time we get to the last page of the
best practices, we are pretty overwhelmed with advice)

The describes element is the metadata placeholder for metadata
that did not fit anywhere else in the metadata document. The
content there could be so generic that It would be difficult to
make good use of it other than human reading. There are exceptions,
of course (STMML)

You can also use a <title> a <description> and other tags (re-using
modules elsewhere in eml) to provide context to the <additionalMetadata>
element, without loss of the intended functionality. There is nothing
special about <describes> per se that cannot be achieved with <any>
other element needed in that generic placeholder. I would say that
the "unexpected" content in <additionalMetadata> will be primarily
to save us from information loss, and sometimes, we use to plug
in other schemas (such the STMML/custom unit consensus workaround).
Perhaps other specify <access> rules there, (not sure why).

However, it is still "optional". So, automated parser
and semantic apps relying on <describes> content will be ill-fated
with the schema as is. Enforcing the use of <describes> at the
recommendation level ( that is, best / common practices) is all we
have now. So, as it is, it is not much different from taking <describes>
out of there. <xs:any> does not preclude the use of <describes>.
May be it ought to be mandatory, we did it so in one EML-2.0.2
candidate. Later, we proposed this other solution because of the
backward compatibility problem, and also, because we did not need it.
Perhaps, part of the reason is not used is because in practice, we
have been forced to remove it from the EML schema due to its
problematic nature.

cheers, inigo

ps: im sending this to the eml-dev list per Matt request.

 
Matthew Jones wrote:
> <describes> is a fundamentally important field.  It cannot be removed 
> without significantly reducing the functionality of the 
> additionalMetadata section.  We use it for annotations of many points 
> in the schema.  It is also the primary mechanism being considered for 
> attaching semantic annotations to eml attributes.  So I would strongly 
> resist such a change.
>
> BTW, this discussion should be occurring on eml-dev.  Please forward 
> it there so all EML contributors are aware of it.
>
> Matt
>
> inigo wrote:
>>
>> Margaret,
>>
>> Comment #4 (Matt Jones's) on bug 2054 (the <describes> 
>> /undeterministic /bug)
>> seems OK, but non-backward compatible.  It is suggested to wrap the
>> xs:any into another element. May be it is unnecessary... bear with me:
>>
>> If we:
>> 1) remove <describes> (//additionalMetadata/describes) from EML2.1
>> 2) and we specify the 0..infinity cardinality of the <any> element 
>> (the child of <additionalMetadata>
>> That is:  change  this  <xs:any processContents="lax"> to
>> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded">
>>
>> Then we fix the issue and we do not make eml-2.0.1 documents invalid, 
>> i checked against doc knb-lter-sbc.7.2
>> that has a <describes> and a <access> under <additionalMetadata>. 
>> This "fix" makes the
>> schema deterministic (and valid)
>>
>> You still can (and perhaps, should, via "best practices") describe 
>> what type of metadata you are adding.
>> Furthermore, you probably want to use "titles", "paragraphs" and the 
>> like when needed
>> under <additionalMetadata>.
>>
>> what do you say?
>>
>> -i
>>
>> ps: i have a backlog of EML-dev threads to respond. but Mark was very 
>> kind to tell me where
>> the discussions are.
>>
>>
>> Margaret O'Brien wrote:
>>> My understanding of the <describes> tag's cardinality is that 
>>> (0..many) allows it to be applied to several discrete parts of the 
>>> doc without the entire <additionalMetadata> section being repeated 
>>> -- although I dont think any applications take advantage of this.
>>>
>>> The only way that changes to <additionalMetadata> can be backward 
>>> compatible is for its contents to become more liberal. And since the 
>>> cardinality of <describes> is already as liberal as it can be, and 
>>> the use of <xs:any> is too liberal, we're stuck. You could also 
>>> achieve validity by setting its cardinality=1, and then the 
>>> <metadata> element isn't necessary  - in fact, this is how I kluged 
>>> my own copy of eml201, way back (with repeated metadata sections). 
>>> I've been migrating to the checked-in fix because it turns out that 
>>> instance docs with the <metadata> tag and 0..many cardinality for 
>>> <describes> are also valid 201 - probably because using <metadata> 
>>> is valid <xs:any>. So anyone who has already anticipated that fix is 
>>> covered.  Others have also done this already - Wade at least, I think.
>>>
>>> for the current fix see:
>>> http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/eml/eml.xsd
>>> discussion of bug 2054 is here:
>>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2054
>>>
>>> The only issue is that original 201 docs cant just migrate forward 
>>> to 210. The biggest current use of additionalMetadata is customUnits 
>>> lists, which are common -- and so this is not trivial.
>> [.......]
>