Simple because Castor XML supports two modes in this context: 'type' and 'element', and the classes generated will differ between these two modes.
Werner Stephen Bash wrote: > Werner- > > Not that I'm an expert on the source gen side of things, but I tend to > agree with you, it all looks good until it comes to compile time... I > guess I don't understand the current contract. Why don't we want to > generate classes for top-level types? Sorry I can't be of more help. > > Stephen > > > On 10/17/06, Werner Guttmann <[EMAIL PROTECTED]> wrote: >> Hi, >> >> As I have got some troubles getting my mind around the following >> sitution, I'd appreciate any kind of feedback. >> >> In the HTML docs at >> >> http://www.castor.org/srcgen-properties.html#Class-Creation/Mapping >> >> it reads that >> >> <quote>Classes will not be generated for elements whose type is a >> top-level type.</quote> >> >> Let's assume the following XML schema fragment: >> >> <element name="Transforms" type="ds:TransformsType"/> >> <complexType name="TransformsType"> >> <sequence> >> <element ref="ds:Transform" maxOccurs="unbounded"/> >> </sequence> >> </complexType> >> >> <element name="Transform" type="ds:TransformType"/> >> <complexType name="TransformType" mixed="true"> >> <choice minOccurs="0" maxOccurs="unbounded"> >> <any namespace="##other" processContents="lax"/> >> <!-- (1,1) elements from (0,unbounded) namespaces --> >> <element name="XPath" type="string"/> >> </choice> >> <attribute name="Algorithm" type="anyURI" use="required"/> >> </complexType> >> >> In the complexType 'TransformsType', there's an unbounded sequence of >> 'ds:Transform' elements, pointing to the global element definition for >> 'Transforms'. In other words, Castor will try to create a >> _transformElementList member of type e.g. java.util.Vector, and create >> several methods for adding/removing/obtaining TransformElement >> instances. So, the Java class TransformsType.java will have methods such >> as ... >> >> public void addTransformElement(int index, >> xml.c1568.xmlsig.TransformElement vTransformElement) >> >> which looks just fine to me.Problem is that - as per above definition of >> the 'type' mode - no class will be generated for TransformElement, >> causing compilation errors. >> >> Can anybody advise how to go about this in a semantically correct way >> without breaking the current contract of the 'type' mode. >> >> Thanks >> Werner >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
