Hi Eamonn I tried out your schema below and it worked for me. The OrderDetails interface was generated as an inner interface on Order which was itself an inner interface of OrderDocument. Similarly for the impl classes.
I believe the rule is that global elements/types are generated as separate classes but local elements/types are defined as inner interfaces within their parent - which is why when you moved the definition of OrderDetails to a global position you saw a separate source file for it. But either way when compiled the classes ought to be there. If not can you post a complete example along with anything you think might be pertinent in your environment and we can go from there? Cheers, Lawrence > -----Original Message----- > From: Eamonn Rohan [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 09, 2006 3:37 AM > To: [email protected] > Subject: Schema generator not generating certain classes. > > Hi everyone, > > I'm developing an application that takes in a schema defined by a third > party and uses XML beans > to parse out the content and also to create the same messages from data > in the app. > > Each xsd file defining a particular message (of which there are about > 17) uses an include statement > to another schema containing common types and this in turn links to a > third file containing dictionary definitions for each > element (some of them end up being enumerations etc.). > > My problem arises when i try to compile an xsd file like this: > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; version="1.00" > id="R2005.1"> > <xs:include schemaLocation="CommonTypes.xsd"/> > <xs:element name="Order"> > <xs:complexType> > <xs:sequence> > <xs:element name="OrderHeader" type="MessageHeaderType"/> > <xs:element name="OrderDetails" maxOccurs="unbounded"> > <xs:complexType> > <xs:sequence> > <xs:element ref="ELEMENT1"/> > <xs:element ref="ELEMENT2"/> > ... > <xs:element ref="ELEMENT17"/> > <xs:element ref="REMARKS" minOccurs="0"/> > </xs:sequence> > </xs:complexType> > </xs:element> > </xs:sequence> > <xs:attribute ref="version" use="required"/> > </xs:complexType> > </xs:element> > </xs:schema> > > The generator gives me a separate document for each Element in the > dictionary file as I would expect it to and also > documents for each of the complex types defined in CommonTypes.xsd > (including one for MessageHeaderType above). > In my OrderDocument interface I get a nested interface for Order which > includes methods like: > addNewOrderHeader which returns a MessageHeaderType, setOrderHeader > which takes in a MessageHeaderType..., however > I also get generated methods for OrderDetailsArray (addNew, set, remove > etc.) that refer to a data type > noNamespace.OrderDocument.Order.OrderDetails which is itself not > generated at all. This means I get no getters or setters for any of the > elements at all and therefore no way to add a new OrderDetails line. > > I have managed to get around this problem by taking the complex type > contained in the OrderDetails section and putting it's contents into > the CommonTypes.xsd file as OrderDetailsType so that the Orders.xsd file > looks like: > ... > <xs:complexType> > <xs:sequence> > <xs:element name="OrderHeader" type="MessageHeaderType"/> > <xs:element name="OrderDetails" type="OrderDetailsType" > maxOccurs="unbounded" /> > </xs:sequence> > <xs:attribute ref="version" use="required"/> > </xs:complexType> > ... > > I was wondering if anyone could shed some light as to why this is > happening (is it something I am doing wrong or a shortcoming of the > application?) > and how I can avoid having to hack at the schemas to get them to compile > correctly. > > I am looking at a situation whereby there may be several revisions of > the schemas throughout the year and I would prefer if at all possible > not to have to change them each and every time a new one gets published. > > Thank you in advance. > > Regards > > Eamonn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
