[eml-dev] EML 2.0.2
Matthew Jones
jones at nceas.ucsb.edu
Mon Mar 31 21:27:33 PDT 2008
Hi Margaret,
How about if we just skip release 2.0.2 and instead call it 2.1.0 so
that we can also include 2054 and 3051 in the release. The only reason
to stick to a 2.0.2 is if the community wants a backwards compatible fix
first, but if we're going to create a 2.1.0 soon anyways then we might
as well just do it now and then push the bugs currently slated for 2.1.0
to a new target milestone (2.2.0) that would follow on later.
Especially given that 2054 has already been worked out and everyone
wants it fixed I think.
Maybe we should ask how many LTER sites and others would be upset if
they had to go through the extra work of making new documents that were
valid using the fix under 2054 if they want to upgrade. If nobody is
concerned, lets just do it now in a 2.1.0 release. Anybody have an idea
about the community feel on this issue (a while back there was
significant resistance to an incompatible upgrade -- maybe sentiments
have changed).
Matt
Margaret O'Brien wrote:
> 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
>>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the Eml-dev
mailing list