[eml-dev] EML 2.0.2

[Christopher Jones]

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
_________________________________________________________________