[eml-dev] EML 2.0.2
Margaret O'Brien
mob at icess.ucsb.edu
Tue Apr 1 09:17:14 PDT 2008
Hi Matt -
I think that moving on to 2.1 with these 5 bugs is the best idea. My
only concern is that once we decide on this step, other requested
features will be added to the list for 2.1.0 and slow its much-needed
release. As far as community attitude - people who need the next
version will be very happy to see it soon, no matter what it's called.
Those who are comfortably creating 2.0.1 will probably continue to do
so, and will upgrade on their own schedules. If 2.1.0 is the minimalist
release, and we discourage other additions till later, then there
shouldn't be any problems. I'll poll the LTER just in case.
You may recall that last summer we had a list of bugs considered "easy
2.1". Some of these could still be targeted for 2.1.1 - for example, the
compatible element additions where xsl templates already exist. They
probably all warrant discussion first.
BTW - I agreed to write a short article (3-4 paragraphs) for LTER's
Spring DataBits on the next version of EML. Can I recruit you as a
co-author? The deadline is 4/15 - soon, but timely.
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
========================
Matthew Jones wrote:
> 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
>
More information about the Eml-dev
mailing list