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

[inigo]

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