Hi Tim, The documentation explains why. Even if it is old it is relevant:
The element method tends to describe the XML instance of the XML Schema you are generating sources for whereas the type method tries to represent the structure outlined in the XML Schema. Since the role of the data-binding framework in essence is to bind XML and Java and not XML Schema; the element method is the default method. I hope it makes sense, Arnaud > -----Original Message----- > From: Leeuw van der, Tim [mailto:[EMAIL PROTECTED] > Sent: Friday, October 03, 2003 10:47 AM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] source generator question: inline > complex types > > > Hi, > > Any reason why 'type' mode is not the default for the source > generator? Backwards compatibility issues? If so, what exactly? > > 'type' mode seems to solve lots of people's problems > (including mine) and if it's the default, such problems > wouldn't even surface. Does using 'type' mode any other > problems that I'm not aware of at the moment? > > Regards, > > --Tim > > -----Original Message----- > From: Keith Visco [mailto:[EMAIL PROTECTED] > Sent: woensdag 1 oktober 2003 19:39 > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] source generator question: inline > complex types > > > > > You'll need to switch to "type" mode, so that classes are > only created for top-level complex-types/elements: > > In the "castorbuilder.properties" file (note the name of the > file is castorbuilder.properties and not castor.properties) > you need to change the javaclassmapping property to be "type" > instead of "element" (and make sure it's uncommented). > > org.exolab.castor.builder.javaclassmapping=type > > --Keith > > Callum Katene wrote: > > > > hi, > > > > i am trying to use the source generator on a couple of very large > > schema files. the problem i am having, is that many of the complex > > types have inline complex types of the same name. the > following schema > > illustrates > the > > point. both Element3 and Element4 have a member called return. the > > source generator attempts to create classes for both regions, but > > because they > have > > the same name, the result is that only one exists, which causes > > problems when unmarshalling, of course. > > > > i know how to use a binding file to give these unique > names, but would > like > > to know if there is a way to do it without the binding > file, because > > of > the > > number of such instances in my schema files. > > > > shouldn't the source generator create Element4Return and > > Element3Return? > > > > any help appreciated. > > > > apologies if this is a stupid question: I'm pretty new to this, so > standard > > newbie disclaimer applies. > > > > callum > > > > C:\castor-0.9.5\V1>java -cp > > \lib\castor-0.9.5.jar;\lib\jta1.0.1.jar;\lib\jdbc-se > > 2.0.jar;\lib\xercesImpl.jar > org.exolab.castor.builder.SourceGenerator > -dest > > test > > -i test2.xsd -verbose > > Creating classes for: Element4 > > Creating classes for: return > > Creating classes for: area > > Creating classes for: Element2 > > Creating classes for: Element3 > > Creating classes for: return > > Creating classes for: region > > C:\castor-0.9.5\V1>dir test > > Volume in drive C is ACER > > Volume Serial Number is A00A-361F > > > > Directory of C:\castor-0.9.5\V1\test > > > > 02/10/2003 02:04 a.m. <DIR> . > > 02/10/2003 02:04 a.m. <DIR> .. > > 02/10/2003 02:04 a.m. 2,560 Area.java > > 02/10/2003 02:04 a.m. 2,991 AreaDescriptor.java > > 02/10/2003 02:04 a.m. 2,111 Element2.java > > 02/10/2003 02:04 a.m. 5,117 Element2Descriptor.java > > 02/10/2003 02:04 a.m. 2,086 Element3.java > > 02/10/2003 02:04 a.m. 4,892 Element3Descriptor.java > > 02/10/2003 02:04 a.m. 2,086 Element4.java > > 02/10/2003 02:04 a.m. 4,892 Element4Descriptor.java > > 02/10/2003 02:04 a.m. 2,576 Region.java > > 02/10/2003 02:04 a.m. 3,003 RegionDescriptor.java > > 02/10/2003 02:04 a.m. 3,157 Return.java > > 02/10/2003 02:04 a.m. 4,801 ReturnDescriptor.java > > 12 File(s) 40,272 bytes > > 2 Dir(s) 3,953,168,384 bytes free > > > > <!--?xml version="1.0" encoding="UTF-8"?--> > > <xsd:schema xmlns:xsd="http://www.w3.org/ 2001/XMLSchema" > > elementFormDefault="unqualified" attributeFormDefault="unqualified" > > version="1. 0"> > > <xsd:complexType name="Element2"> > > <xsd:sequence> > > <xsd:element name="myname" type="xsd:string"/> > > </xsd:sequence> > > </xsd:complexType> > > > > <xsd:complexType name="Element3"> > > <xsd:sequence> > > <xsd:element name="return"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element name="region" > > type="Element2"/> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > </xsd:sequence> > > </xsd:complexType> > > <xsd:complexType name="Element4"> > > <xsd:sequence> > > <xsd:element name="return"> > > <xsd:complexType> > > <xsd:sequence> > > <xsd:element name="area" > > type="Element2"/> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:element> > > </xsd:sequence> > > </xsd:complexType> > > </xsd:schema> > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
