Bug in eml2 for inline element type defination

[Matt Jones]

Peter,

We already have an EML 2.0.1 target milestone available in bugzilla, as 
well as the default milestone of 'Postpone'.  So, if you enter a new 
bug, you can accept the default 'Postpone', or you can retarget it at 
2.0.1.  I think we should accumulate our list of bugs there, and decide 
what to do with them as we get a greater sense of the issues.  I've 
asked Jing to enter the issue he reported into bugzilla, so it should 
show up soon.

That's a bummer about the year -- I thought we did that.  Maybe it was 
just for the publicationDate field?

The change Jing proposes simply loosens the content allowed in 'inline'. 
  The change you propose also loosens the content allowed in 
'temporalCoverage'.  To me, both are legitimate bug fixes that will have 
no serious consequences because all 2.0.0 documents would also be valid 
with those changes made in a 2.0.1 release.  Lets accumulate a bit more 
and then decide if and how we might do a bugfix release.

Thanks.
Matt

Peter McCartney wrote:
> 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.
> 
> 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.
> 
> 
> 
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental-Studies
> Arizona State University
>  
> 
> 
> -----Original Message-----
> From: Jing Tao [mailto:tao at nceas.ucsb.edu]
> Sent: Thursday, March 06, 2003 7:44 PM
> To: jones at nceas.ucsb.edu; higgins at nceas.ucsb.edu; 
> berkley at nceas.ucsb.edu; eml-dev at ecoinformatics.org
> Subject: Bug in eml2 for inline element type defination
> 
> 
> Hi, everyone:
> 
> Today, when we tried to upload an eml2 doucment with inline charater 
> data to Metacat, a error was shown that inline element can only have 
> element children and  can't have a character child(inline element is 
> defined in eml-resource.xsd). However, inline element supposes to 
> support characters children. Something is wrong.
> 
> We took a look on the definition and found the children of inline is 
> defined as "any". So it seemes schema only consider the "any" just for 
> elements come from any namespace and we couldn't put characters in 
> there. This is different to dtd "any". In dtd, "any" can be considered 
> as elements or characters.
> 
> Dan found an text type defined in w3c primer web site: <xsd:complexType 
> name="text">  <xsd:complexContent mixed="true">
>   <xsd:restriction base="xsd:anyType">
>    <xsd:sequence>
>     <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
>    </xsd:sequence>
>    <xsd:attribute ref="xml:lang"/>
>   </xsd:restriction>
>  </xsd:complexContent>
> </xsd:complexType>
> 
> It allows an unrestricted mixture of character content and element 
> content from any namespace.
> 
> I wrote an very simple schema which contains the text type and a xml 
> instance. Then using xerces to validate the xml instance by the schema. 
> It works fine if we delete the line: <xsd:attribute ref="xml:lang"/> in 
> the complex type definition.
> 
> So, can we use this type to replace the anonymous type for inline or 
> other place which use "any"?
> 
> By the way, Matt, Dan and Chad. I figured out why anoymous type for 
> inline element didn't work in this afternoon(I didn't put the line 
> mentioned should be delete in eml-resource.xsd). The reseaon is I didn't 
> put attributes "minOccurs="0"" in xsd:any element. If put it, works 
> fine. Else gives us the error. It is weild because we can omit 
> minOccurs. Is this a bug for xerces?
> 
> Thanks.
> 
> Jing
> 
> 
> Jing Tao
> National Center for Ecological
> Analysis and Synthesis (NCEAS)
> 735 State St. Suite 204
> Santa Barbara, CA 93101
> 
> 
> _______________________________________________
> eml-dev mailing list
> eml-dev at ecoinformatics.org 
> http://www.ecoinformatics.org/mailman/listinfo/eml-dev
>