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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
