[eml-dev] EML 2.0.2

Tue Mar 25 10:10:42 PDT 2008

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.
#2703    eml not valid is xmlSpy versions 2006+, eml-text and 
eml-documentation (maybe)
#3163    eml-literature schema - cardinality of volume/pageRange
I say "maybe" on #2703 because Inigo's work had contributed 10-12 
changes to the schema, and I'm plowing through them one by one. Some 
look like they will break backward compatibility, so that and the 
conclusion on the other bugs made it prudent to get this info to you all 
now.

The story on the dropouts:
#2054    use of <any> in additionalMetadata is invalid given the 
cardinality of its sibling <describes>
Existing 2.0.1 documents,will not be compatible with the fix for 2054, 
since the fix requires that additionalMetadata have a <metadata> child. 
2.0.2 documents will be valid 2.0.1 since <xs:any> can accomodate the 
presence of <metadata>. If someone can see a way this can go into 2.0.2 
(like by bending the backward compatibility rule) speak up. The one way 
I can see is to require the <describes> element -- then the <xs:any> can 
remain. See the notes added to 2054 
(http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2054) for why this 
is not recommended. The current patch seems to be a deal breaker for 2.0.2.

#3051    units missing from standardUnit restriction list (doesn't match 
eml-unitDictionary.xml)
Not compatible if the eml-unitDictionary.xml is kept with EML. If this 
doc moves with 2.0.2, then a document could be created which includes a 
standard unit from the new restriction list that is not in the EML2.0.1 
restriction list.

#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

#2083    dimension 'current' is wrongly entered as 'charge'
This fix included changes to stmml schema, which will not be backward 
compatible if anyone used the errant version of stmml.xsd to create a 
customUnit using this wrong unitType.

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

One note: none of this is checked into cvs at this time. I've been 
working with the HEAD, and it seems like at least a couple of the 
changes already checked into cvs actually belong on the 2.1 branch, but 
that branch has checkins that are incomplete. So I'm hesitant to add 
anything till I figure out where it goes (a good place for one of you 
knowledgeable historians to advise).

Thanks -
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:
> Margaret,
>
> This list looks good to me, with a couple of caveats.
>
> 1) 1662: I don't think these changes are mature enough for a 2.0.2 
> release.  They really should be thought out more carefully, as the 
> system for IDs and reference pointers is fundamentally important and 
> will have lasting consequences for how people design applications that 
> use EML.  I would suggest this bug be moved to 2.1.0, and any 
> associated changes be backed out of CVS.  This probably requires a 
> more extensive discussion.
>
> 2) 3181: as I indicated in my previous email, I would not support 
> wholesale conversion of xs:string to txt:TextType. A more judicious 
> list of fields to be changed based on the merits of each case is a 
> better approach.
>
> Matt
>
> Margaret O'Brien wrote:
>> Hi folks -
>> FYI, These are the changes to the eml schema which have been targeted 
>> for 2.0.2. Priority was given to important changes (e.g. validation) 
>> that won't break existing docs, or simple ones that don't need to 
>> wait till 2.1.0 (cardinality, typing). Most of these do not require 
>> updates to the stylesheets, except as noted.
>>
>> 1662    id key definitions in EML
>
>> 2054    use of <any> in additionalMetadata is invalid
>
>> 2083    dimension 'current' is wrongly entered as 'charge'
>
>> 2703    eml not valid is xmlSpy versions 2006+, eml-text and 
>> eml-documentation
>
>> 3051    units missing from standardUnit restriction list (doesnt 
>> match eml-unitDictionary.xml)
>
>> 3163    eml-literature schema - cardinality of volume/pageRange
>
>> 3181    xs:string to ComplexType TextType, mixed true (plus stylsheet 
>> update)
>
>
>> plus other stylesheet fixes TBD
>
>> 3166    remove extra "attributeindex" parameter in eml-settings.xsl 
>> (stylsheet update)
>
>>
>> Stay tuned for eml-2.0.2rc1, keep those cards and letters coming, and 
>> have a good weekend -
>> margaret
>>
>>
>