proposed EML 2.0.1 release

[David Blankman]

Since I took care of making most of the changes, I have not attempted 
review my own work.

I am especially please that this release is finally about to be 
available. There are a lot of eml files that I have converted for LTER 
sites that do not have precision metadata.

Thw issue of precision is a complex one. As I may have said earlier, the 
issue of precision definition should be one that is discussed with the 
broader ecological research community. Barbara Benson at the NTL LTER 
site has pointed out that for some of their measurements precision is a 
"fuzzy" issue and not easily reducible to a single number.

In my visits to LTER sites, many of the researchers felt that EML had 
been imposed upon them rather than being part of the development 
process. A broad discussion of precision and perhaps other parts of EML 
will help to counter the impression that EML is an imposition.

David Blankman

Christopher Jones wrote:

> 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
> _________________________________________________________________
> _______________________________________________
> eml-dev mailing list
> eml-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/eml-dev    


-- 
David E. Blankman, m.c.r.p
EML Integration Developer
Ecoinformatics Consultant
Member, EML Development Group
921 Ortega, NW
Albuquerque, NM 87114-1417
phone: (505) 450-6045

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20040715/03e9d5eb/attachment.htm