Bug in eml2 for inline element type defination

[Peter McCartney]

Wasn't saying we shouldn't expect eml documents to validate or that we
shouldn't continue to solve these things collectively - just that I don't
find it much help in using the file in the context I mentioned. Since so
many things in eml are optional, you wind up writing code to check the
existence of elements all the time anyway. Checking the quality of files to
be inserted into an archive as Jing was doing is a different case where
validation is probably more important.


Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental-Studies
Arizona State University
 


-----Original Message-----
From: Scott Chapal [mailto:scott.chapal at jonesctr.org] 
Sent: Friday, March 07, 2003 10:12 AM
To: Peter McCartney
Cc: 'Jing Tao'; jones at nceas.ucsb.edu; higgins at nceas.ucsb.edu;
berkley at nceas.ucsb.edu; eml-dev at ecoinformatics.org
Subject: Re: Bug in eml2 for inline element type defination



Peter,

Peter McCartney <peter.mccartney at asu.edu> writes:

> Well this seems to be an important issue. We are in the middle of a 
> remodel of Xylopia to use EML documents as a container for passing 
> data between modules using the inline element. Given all the problems 
> with validating EML documents, I think its easier to just check an EML 
> document to see if it has what I need rather that coping with a 
> million other reasons why the file might not be valid depending on the 
> parser you use. Therefore, we havent detected this problem.

I've heard you voice similar objections before, but I don't understand what
you are opposed to.  The validitation requirement/feature in XML schema?  If
so, why don't we just hack metadata notes in ASCII and pass them back and
forth?  I don't see validation as debatable, per se, because it equates to
the structured part of "Structured Metadata".  How that validation is
defined is the difficulty.  If xerces or any other tool has bugs, well
that's a horse-of-a-different-color.


> There are other equally severe problems we've noted, however! The 
> absence of a union in the temporal coverage field prevents us from 
> putting a year as opposed to a calendar date. Id like to make sure 
> that if we are developing a target list for 2.x bugfixes, we have a 
> system to do it logically. Do we need to define a new version target 
> in bugzilla so that we can start putting these in there rather than 
> helterskelter through email? Ive held off adding anything for fear 
> that it gets attached to 2.0.0 which seems like it should be closed.

I would think "bugfixes" would be attached to 2.0.x.

-- 
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030307/479c0030/attachment.htm