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

[inigo]

Margaret,

It would be nice to have a legal EML schema -sure-
To my knowledge, both solutions addressing the offending
2054 (aka describes) bug suggested here make the EML
one step closer to be XML Schema rules compliant.

Im not sure what is the delay you are referring to..however,
after a second read of Matt's position - "strong opposition"
sounds like a "veto", I would say that for the sake of moving
along let's go with the enveloping tag to the <describes> and
<xs:any> children. Anyway, I said in the previous two posts
I said Im OK with whatever eml-dev is pleased with.

I'll test the release candidate for schema validation errors
when you guys have it ready.

thanks!
inigo

Margaret O'Brien wrote:
> I understand your desire, Inigo, to leave the final release of the 2.0 
> series in a schema-compliant condition. But I wonder if it's really 
> worth the effort and delay, given that we'd be moving on to 2.1 in 
> short order anyway. The 2.1 release candidate should be ready for 
> checkout early next week, after a little housekeeping.
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA  93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu
> http://sbc.lternet.edu
> ========================
>
>
>
> inigo wrote:
>> margaret:
>>
>> calling the new EML candidate schema less functional
>> is inaccurate, to put it mildly.   the alleged lost
>> functionality you  refer to is currently given by the
>> suggested  use of the element, not by the schema element
>> <describes>. like in many instances, functionality is
>> provided by the "guidelines", "specifications" and
>> "best practices", the <describes> element per se
>> provides nothing, and none of both debated solutions
>> preclude the actual "recipe" to use <describes>.
>>
>> that is, removing <describes> from the schema
>> and specifying cardinality to <xs:any> does not prevent
>> any user to place a <describes> in there, just as you
>> have been doing. that particular fix makes the use
>> of "describes" legal.
>>
>> we can make a count of documents that use <describes>
>> as prescribed in the specification, or that use <describes>
>> at all. it is besides the point, but i'll be happy to send
>> the list the stats.
>>
>> also, i dont see how is it dangerous. what danger exactly?
>> anyone following the use of <describes> can freely
>> cotinue to do so, and the rest will just go on.
>> the debated solutions to 2054, functionality wise, are the
>> same; that is, both solution accept the use of "describes"
>> as suggested in the eml specification.
>>
>> i personally do not mind which way eml-dev decide to go.
>> it would have being nice to remove bugs from EML.
>> EML as is actually XML schema rules compliant, that is all.
>>
>> i apologize to repeat the arguments in emails, but i
>> think it is important to clarify misinterpretations.
>>
>> cheers, inigo
>>
>> Margaret O'Brien wrote:
>>  
>>> Hi all -
>>> Regarding the additionalMetadata section in general:
>>> My opinion is that to relax its content to simply <xs:any> would 
>>> indeed make it a hack -- whereas its current function is to augment 
>>> existing EML sections. The community already knows that some 
>>> sections may need future enhancements (e.g. units and access), and 
>>> in fact, the patterns of use of additionalMetadata may provide 
>>> guidance for extensions and/or modifications of these.
>>>
>>> It seems we have 2 choices wrt the next release:
>>> A. Further relax additionalMetadata to create one more release 
>>> (2.0.2) that is schema-valid and then quickly produce v2.1 
>>> (returning the functionality that was removed), or
>>> B. Move straight to 2.1 and keep all current functionality.
>>>
>>> The primary (only?) drawback to choice B is that some EML users may 
>>> not be able to move right away to v2.1. However, those who currently 
>>> have no problems creating 2.0.1 can continue to do so, updating 
>>> their systems on their own schedules. Those frustrated with 201 will 
>>> welcome the upgrade. User groups could evaluate their most common 
>>> patterns of additionalMetadata use and create XSL stylesheets to add 
>>> the <metadata> tag.
>>>
>>> The repercussions of choice A seem more subtle to me. It seems 
>>> dangerous (or at least odd) to have a version of EML (2.0.1) which 
>>> has more functionality that its successor, 2.0.2. Yes, existing docs 
>>> would be unaffected, and there may be no apps which make use of the 
>>> optional <describes>. But users who take advantage of 2.0.2's lax 
>>> treatment of additioalMetadata in new documents will need to plan 
>>> for their eventual upgrade (ie, add a describes element and 
>>> associated ids). It may be that upgrading docs to 2.1 from 2.0.2 is 
>>> actually more difficult than from 2.0.1, making a EML2.0.2 release a 
>>> disservice in the long-run.
>>>
>>> Maybe some with experience in software versioning practices could 
>>> comment here. Those of us with a user-POV would benefit from this 
>>> wisdom.
>>>
>>> regards -
>>> Margaret
>>>
>>>
>>>
>>>
>>>
>>>
>>>