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

Fri Apr 4 14:58:26 PDT 2008

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
>>
>>
>>
>>
>>
>>
>>
>>
>> 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
>>>  
>>>
>>>       
>>     
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>   