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

Fri Apr 4 09:38:57 PDT 2008

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

inigo wrote:

>Hi Chris,
>
>Thanks for your detailed comments. I am really glad that
>part of the eml-dev community is engaging firmly on these
>enhancements.
>
>  
>
>>I think it's good to remember that EML is a specification developed by  
>>the *ecological community*, with the LTER Network being one component  
>>of that larger community. The LTER 'Best Practices' have been  
>>developed within the LTER to help guide the network in producing EML,  
>>but it is by no means part of the specification.  Other groups will  
>>benefit from the experiences of the LTER in using EML, and vice versa.
>>  
>>    
>>
>Yes, I don't forget. Sorry if I gave you that impression. I was trying 
>to illustrate the
>fact that the <describes> element was barely used by a part of this 
>community you refer to.
>
>Extensibility in <eml> through <additionalMetadata> does not seem 
>elegant to me. It
>feels more like a hack, rather than a formal procedure to enhance or 
>extend a reputable
>standard. But that may just be my impression. 
>
>  
>
>>Please read the EML 2.0.1 specification. Access control rules in  
>>Section 2.4.1 state:
>>
>>"Exceptions for particular data components of the package can be  
>>controlled at a finer grain by using an access description in the  
>><additionalMetadata> element that points at a particular  
>><distribution> element by referencing its unique id. An access control  
>>document may be defined, or referenced, from this location, and the  
>><describes> element is used to point to the distribution that is to be  
>>controlled via its "id" attribute."
>>
>>  
>>    
>>
>This sounds like last minute practical solution to address a specific
>problem. I think the reason of existence of <additionalMetadata>
>should be beyond that example.  The fix proposed does not prevent
>using  the <additionalMetadata> the way expressed in the Section 2.4.1
>
>If the only use of this tag was to provide a placeholder to fine
>grain (or address shortcomings) the access rules, perhaps
>the schema would have been enhanced to enable encoding of
>more complex access rules. or just add a tag named <fineGrainAccessRules>
>inside, or by the side of <additionalMetadata>
>  
>
>>You seem to be lobbying for the removal of the <describes> tag, which  
>>is integral to maintaining separate access control rules for both  
>>metadata and data components of an EML package.  In my opinion, this  
>>would be a step backwards.  There are recognized and documented  
>>problems with the access control constructs in EML, and possible  
>>backwards-incompatible fixes are described in Bugzilla, but a  
>>wholesale removal of <describes> would be detrimental to the current  
>>access control functionality.
>>  
>>    
>>
>Im not lobbying for anything but helping solve a quite
>embarrasing problem: the EML schema as is does not
>comply with the XML schema rules.
>
>In fact, Im just thinking that removing <describes>
>and refining the cardinality of <xs:any> would solve
>such problem with some limited impact.  What is
>the solution that you are proposing? im OK keeping
><describes> as mentioned in bugzilla's 2054 comment #4,
>we just pointed out that this way may be better
>for the reasons explained.  Im fine expanding the branch
>with an enveloping element. What Im not OK with is
>with an schema that is not compliant with the XML schema
>rules. What do I say when I promote EML even beyond
>the ecological community: "Well yeah, the EML schema is
>buggy, but we know about it, we are working on it" How
>far do you think that this sort of explanation will hold
>without eroding the patience and trust of the current
>and potential users?
>
>  
>
>>>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.
>>>    
>>>      
>>>
>
>  
>
>>>Actually, the rules governing the use of the <describes> tag is  
>>>strictly enforced by the applications that employ the EML parser (for  
>>>both EML and XML validity).  You may want to ask Chad and Matt about  
>>>how the parser enforces the rules - they wrote the EML parser.
>>>    
>>>      
>>>
>there is a slight misunderstanding: i meant machine parsing beyond
>validation  check. parsing it to use in data synthesis, integration and 
>the like.
>i also see how structured content within <additionalMetadata>
>may be used by a parser successfully, but it is not inherently
>build by the current structure. The uses that you point out are
>spelled out in the "documentation" which mentions one or two
>ways that you may use the <additionalMetadata> tag. 
>  
>
>>If you plan to lobby for the removal of the <describes> tag, you must  
>>replace all of the functionality that it provides (described above and  
>>more) with other constructs without sacrificing the fundamental  
>>feature of EML: extensibility.  EML is not perfect by any means.  The  
>>community will likely move on to more semantically-oriented languages  
>>in the future, but the features that were designed into EML have  
>>catapulted groups within the ecological community out of free-form  
>>text descriptions, proprietary binary file descriptions, and/or no  
>>descriptions at all.
>>  
>>    
>>
>
>the solution that we proposed enables in practice the same
>functionality that eml-2.0.1:  A user of this EML-2.1 candidate
>release may very well place under <additionalMetadata>
> a <describes>, and other content as advised in the "documentation"
>"guidelines", "best practices" or just his own will.  The
>difference is that the solution proposed here fixes a bug.
>
>Moving on to semantic mediated languages may be the future.
>In the meantime, we need to work with what we have and
>make it better. That's why we are discussing, and I appreciate
>your time, consideration and explanations.
>  
>
>>Thank you to all of those that toiled over the current version of EML,  
>>and those who are toiling over future versions now.
>>
>>Chris
>>_________________________________________________________________
>>christopher jones       cjones at msi.ucsb.edu      (805) 680-5946
>>marine science institute  university of california, santa barbara
>>_________________________________________________________________
>>  
>>    
>>
>
>_______________________________________________
>Eml-dev mailing list
>Eml-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>  
>

-- 
========================
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
========================