You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/03/27 00:37:19 UTC
XSD woes
Javadogs,
According to my xsd expert, we're misusing xsd in the published ns/
jdo xsd files, and if we want to preserve the existing semantics we
need to change the xsd and add some code to jdo implementations.
Specifically, if there is not a definite content between the
beginning and ending extension, then the parser is correct to
complain. He suggests that we redefine the xsd to allow a mixture of
extension and other elements. If more restrictions are needed, such
as only one occurrence of datastore-identity, primary-key, and
inheritance, then the implementation needs to enforce this and not
depend on the parser.
The implication is that we redefine the xsd for all the elements that
currently allow extension, and put more of the burden on the jdo
implementation to catch errors.
As part of this, I'd be willing to relax the requirement that
extensions occur only at the beginning or at the end of elements.
I'll have a more specific proposal for your review later.
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: XSD woes
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
I looked at the jdo_2_0.xsd and changed it the way you described in your
email. I changed the sequences including a list of extensions at the
beginning and at the end into choices. I also added some documentation
enclosed in <xs:annotation><xs:documentation> ...
</xs:documentation></xs:annotation> describing which subelements must
not occur more than once. You find the updated xsd attached. Please have
a look.
I propose to renamed the file to jdo_2_1.xsd and change the version
entry to 2.1, since this will go into the JDO 2.1 Maintenance Release.
What do you think?
Regards Michael
> Javadogs,
>
> According to my xsd expert, we're misusing xsd in the published ns/jdo
> xsd files, and if we want to preserve the existing semantics we need
> to change the xsd and add some code to jdo implementations.
>
> Specifically, if there is not a definite content between the beginning
> and ending extension, then the parser is correct to complain. He
> suggests that we redefine the xsd to allow a mixture of extension and
> other elements. If more restrictions are needed, such as only one
> occurrence of datastore-identity, primary-key, and inheritance, then
> the implementation needs to enforce this and not depend on the parser.
>
> The implication is that we redefine the xsd for all the elements that
> currently allow extension, and put more of the burden on the jdo
> implementation to catch errors.
>
> As part of this, I'd be willing to relax the requirement that
> extensions occur only at the beginning or at the end of elements. I'll
> have a more specific proposal for your review later.
>
> Craig
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin