[eml-dev] EML 2.0.2

[Margaret O'Brien]

Chris is right - In the case of 3181, I was validating a 2.0.2 instance 
against 2.0.1 - sorry. Chris will create a list of candidates which 
might be switched from xs:string to xs:TextType.

The #2703 issues are resolved, and it appears that these changes will 
only affect the schema and not the instance documents. So #2703 should 
be backward compatible too.

To summarize: the EML-2.0.2 (ie, backward-compatible) bugs are:
2703    eml not valid is xmlSpy versions 2006+, eml-text and 
eml-documentation
3163    eml-literature schema - cardinality of volume/pageRange
3181    Some elements may be changed from xs:string to ComplexType 
TextType, mixed true (plus stylsheet update)

And the high-priority but incompatible bugs are:
2054    use of <any> in additionalMetadata is invalid
3051    units missing from standardUnit restriction list (doesnt match 
eml-unitDictionary.xml)

margaret


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



Christopher Jones wrote:
> Margaret,
>
> Thanks for the update on the status of these bugs/features.  I agree  
> with Matt about #1661, in that the changes were made in 2004, but just  
> haven't been tested thoroughly with systems that ingest or process EML  
> documents.
>
> On Mar 25, 2008, at Mar25---11:10:42 AM, Margaret O'Brien wrote:
>   
>> Given the backward compatibility rule that Matt outlined, only 2 bugs
>> are candidates for EML2.0.2.  These failures turned up after running
>> tests with 2.0.1 docs on 2.0.2 candidate-fixes.
>> #3181    xs:string to ComplexType TextType, mixed true (judiciously
>> applied)
>> In 2.0.2, some elements (e.g., <title>) could be allowed to have child
>> elements (e.g. <emphasis>) which is not compliant with 2.0.1
>>     
>
> I think the backward compatibility rules the we've traditionally  
> followed (and that Matt listed) would actually allow changes such as  
> those described in #3181.  No, the changes won't be forward-compatible  
> (i.e. 2.0.2 documents won't validate against the 2.0.1 schema), but  
> they will accommodate existing EML 2.0.1 documents (i.e. a 2.0.1  
> document *will* validate against a 2.0.2 schema).  For instance, by  
> adding the 'type="mixed"' attribute to the TextType, we are allowing  
> free text in the element, as opposed to requiring a <para> or  
> <section> child.  In this case, this would be the change that would  
> make this backward-compatible with existing 2.0.1 documents.
>
>   
>> Releasing a v2.0.2 that includes 2703-fixes but not 2054 is (imho)  
>> lame
>> -  since  the schema isn't valid without #2054. So that leaves one  
>> small
>> cardinality change for 2.0.2. Hardly worth it. What if we skip 2.0.2
>> altogether and move on to 2.1? The decision seems to hang on bug 2054
>> (and finishing 2703). To accomdate current uses, it would be best if
>> 2.1.0 were the minimalist version with bug-fixes that 2.0.2 was  
>> supposed
>> to be, and for the most part, 2.1.0 docs would look very much like
>> 2.0.1. The list of bugs targeted for 2.1.0 could be expanded now,
>> although there is a great benefit in getting the validation fixes out
>> soon (no matter what version it's named). The bigger and better EML
>> would then start at 2.2
>>     
>
> I'd consider my comments above before we skip on to releasing EML  
> 2.1.0.  #2054 issues withstanding, I think there are a number of  
> possible backward-compatible bug fixes.
>
> About #2054: When EML 2 was being created, XML Schema validating  
> software was fairly scarce since the W3 had just recently released the  
> full recommendation.  Schema validation was done using the W3 XSV  
> validator at:
>
> http://www.w3.org/2001/03/webdata/xsv
>
> In fact, if you point the validator at http://knb.ecoinformatics.org/knb/schema/eml-2.0.1/eml.xsd 
> , it validates fine (although it gives warnings about lax parsing of  
> eml-documentaion):
>
> Schema validating with XSV 3.1-1 of 2007/12/11 16:20:05
>      * 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
>
> That said, both XMLSpy and Oxygen are useful tools, and validation is  
> certainly an issue.  Either they interpret the recommendation  
> differently than the XSV validator, or they are more robust than the  
> XSV validator.  Can anyone comment on this?
>
> In using Oxygen, the Xerces parser validates schema documents with an  
> 'external validation' option set to 'http://www.w3.org/2001/XMLSchema.xsd' 
> .  This schema document was last updated with release of XML Schema  
> 2nd edition in July 2004.
>
> I don't have an answer regarding 2.0.x releases without addressing bug  
> #2054, except that a 2.0.2 release may acknowledge the issue in the  
> release notes and that we should work on a 2.1.0 backwards- 
> incompatible release soon thereafter.  If you validate with XSV, the  
> schema seems fine.  If you validate with the commercial tools, yes, it  
> is 'lame' =).  However, releasing EML 2.1.0 is a big undertaking, in  
> terms of the breadth of the backwards-incompatible changes (including  
> major access control restructuring), and in terms of the software  
> changes to existing EML-based applications.  I doubt it will be a  
> quick process.
>
> Cheers,
> 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
>