[eml-dev] EML 2.0.2
Matthew Jones
jones at nceas.ucsb.edu
Tue Apr 1 09:45:40 PDT 2008
Sounds good to me, Margaret. I'll be happy to co-author the article
with you.
Matt
Margaret O'Brien wrote:
> 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
>>
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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