proposed EML 2.0.1 release

[Christopher Jones]

EML dev'ers,

I was also able to go through these changes, and things look good for a 
bugfix release.  It seems important to talk through the bigger changes 
for an EML 2.1.0 release later.  I am getting one irksome error when 
validating the whole suite of .xsd files against the XML Schema parser 
at http://www.w3.org/2001/03/webdata/xsv:

Here are the good results:

# Validation was strict, starting with type [Anonymous]
# The schema(s) used for schema-validation had no errors
# No schema-validity problems were found in the target

But I kept getting:

Schema resources involved

Attempt to load a schema document from 
eml://ecoinformatics.org/documentation-2.0.1
  (source: new namespace) for
    eml://ecoinformatics.org/documentation-2.0.1,
     failed:

couldn't open

It doesn't seem like a show stopper at all, because validation of the 
eml-documentation.xsd file alone worked fine.  Perhaps someone else can 
see an easy fix that I couldn't.

> In your review, please pay particular attention to the changes for 
> properly allowing inline data (bug 1008), the changes in access control 
> documentation that significantly alter and fix how access rules are 
> interpreted (bug 1132), and changes to the precision field cardinality 
> and documentation (bug 1124).
Bug 1008: Fixing the <inline> element:

These are good changes that result in the ability to use <inline> as it 
was originally intended (pasting your data inline!).  Thanks, Dan, for 
finding that snippet of code at w3.org.

Bug 1132: Clarifying the acl documentation:

It's obvious that we need to learn from our mistakes before we can truly 
implement access control descriptions in XML.  The changes here look 
good.  The extent of this backwards compatible fix will *at least* allow 
for correct interpretation of the access control where metadata vs. data 
are concerned.  I agree that the original design is going to need some 
non-backwards compatible changes, but we'll have to tackle those in the 
next release after discussion.  For now, it seems wise to only honor the 
top level resource access control, plus data-level access control in the 
<distribution> tag as is expressed in an <additionalMetadata> tag.  This 
will give us the ability to say "yes/no you can view my metadata, *and* 
yes/no you can view my data".

Bug 1124: Making precision optional:

Again, pragmatic issues help define the standard.  Yes, <precision> is 
critical to creating automated applications, but I see the need to make 
this optional given the fact that many legacy datasets do not include 
precision, nor is it easy to track down or interpret retroactively. 
 From a community standpoint, we should encourage people to use it, but 
making it optional will help in the adoption of structured metadata.
Thanks, Matthew, for catching the measurementScale typo.

Best,
Chris
_________________________________________________________________
christopher jones    cjones at lifesci.ucsb.edu    (805) 680-5946
marine science institute  university of california, santa barbara
_________________________________________________________________