[eml-dev] [Bug 3232] - EML parser limitations

[Margaret O'Brien]

Fixing bug 2054 does not force an upgrade, so on its own it's really a 
non-issue.

However, there is a real problem looming in bug 3232 - which is that EML 
2.0.x may be doomed to extinction. A fully-functioning parser would 
reject those schemas outright, along with their instance documents. The 
broken/lax parser allows 2.0.x to exist; a schema-checking parser will 
not.  This bug could force an upgrade - and we need ideas for the best 
way to approach a parser repair that minimizes the impact on content 
providers who can't quickly retool their code for a valid schema.

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
========================



inigo wrote:
> point 1) was addressed recently in exchanges with margaret - with the 
> current 2054 fix, none of the existing
> eml docs that use "additionalMetadata" will validate against 
> eml-2.1.0rcx.  How much of an issue is that?
> not sure. The automated procedures that are in place to generate 
> eml-2.0* would have to be tweaked to
> insert the now mandatory "metadata".
>
> inigo
>
>
> bugzilla-daemon at ecoinformatics.org wrote:
>   
>> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3232
>>
>>
>>
>>
>>
>> ------- Comment #5 from mob at icess.ucsb.edu  2008-04-23 13:27 -------
>> With regard to comment #3 (2 failed docs): 
>> 1. the first test shows how many 201 docs will fare when validated against 210
>> -- the now-required <metadata> element is missing. The only 201 docs which will
>> pass will be those from people who pre-implemented the bug 2054 fix.  
>>
>> 2. the second error is more complicated. There had been a partial fix of bug
>> 1662 that was checked into the head, but was not in the release of eml201.
>> See comment #4 on bug 1662: the code which added attributes to <references> was
>> merged into a branch with other target-unspecified changes. Since it had been
>> in the head, there was always the possibility that someone with a recent
>> checkout might use it (as Callie has). If the use of that attribute is
>> pervasive, and if it's acceptable to address 1662 partially for now, then it
>> can go back in the head. advice/opinions, please.
>> _______________________________________________
>> 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
>