[eml-dev] EML 2.0.2

Tue Mar 25 12:29:05 PDT 2008

Dear Callie,

To understand EML bugs, is best to close Morpho and
use an XML editor that can examine and proof an XML
schema (EML is an instance of an XML schema).

Examples of such editos are oXygen and XMLSpy
(professional edition or better, not the "home/free edition")

By using these editors, you may be able to weed out bugs
that originate in Morpho or/and EML. Note that many
"EML bugs" should be categorized as "Feature Requests".
I think we abuse a bit of the "bug" name designation in this
list... we use it as an umbrella term for "all the things we'd
like to see in EML". whether bugs, enhancements, structural
changes, feature requests and the like.

Cheers, Inigo

Callie Bowdish wrote:
> Hi Margaret,
>
> Thanks for tackling this, Margaret. In some cases it is hard for me to 
> distinguish where a bug is an eml bug or a Morpho bug. The 
> additionalMetdata area does appear to be one of the more difficult areas 
> with working with Morpho and I do not know how much of it is Morpho and 
> how much of it is eml. It is challenging to know the difference.
>
> Because I work with the end users who enter in data using Morpho I would 
> really like to untangle the Morpho bugs from the eml bugs. It would be 
> great to have the eml problems updated before trying to fix some of the 
> many related problems with Morpho.
>
> It looks like it is hard to determine what to do regarding backwards 
> compatibility. Is there any best practices regarding handling this when 
> it comes up?
>
> Callie
>
> 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.
>> #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
>>>>
>>>>
>>>>       
>>>>         
>> _______________________________________________
>> Eml-dev mailing list
>> Eml-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>>   
>>     
>
>   