| Michael Bouschen 2007-04-06, 7:11 pm |
| 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
|