I just wanted to mention that it appears as though none of the
top-level attributes are getting any code generated for them.
If I change the top-level attribute declarations to named simpleTypes
(ie, make a simpletype called classification instead of having a
top-level attribute named classification,) then remove the refs under
the attribute group and make them simply attributes of the same type
as the named simpleTypes (ie <xsd:attribute name="classificatin"
type="classification/>,) then it all works as one would expect -
Except without inheriting the prefix of the parent type where they are
included.
If that's unclear, I can post an example schema tomorrow. The net was
down at work, so I cannot provide one now. And now, I must go to
class...
On 10/14/05, Stephen Dennison <[EMAIL PROTECTED]> wrote:
> I'm not sure if this is related, but I just hit another issue where a
> class isn't being generated, and instead the parent class is using
> String as the type for the field that has the missing class.
>
> Schema looks like this:
> ...
> <xsd:complexType name="MessageType">
> <xsd:simpleContent>
> <xsd:extension base = "MessageSimpleType"/>
> </xsd:simpleContent>
> </xsd:complexType>
>
> <xsd:simpleType name="MessageSimpleType">
> <xsd:restriction base="xsd:string">
> <xsd:enumeration value="type1"/>
> <xsd:enumeration value="type2"/>
> <xsd:enumeration value="some"/>
> <xsd:enumeration value="other"/>
> <xsd:enumeration value="values"/>
> ...
> </xsd:restriction>
> </xsd:simpleType>
> ...
>
> In castor 0.9.5.2 it resulted in the following code:
> ...
> public class MessageType implements java.io.Serializable {
> ...
> private mypackage.types.MessageSimpleType _content;
> ...
> }
>
> In castor 0.9.9 it results in the following code:
> ...
> public class MessageType implements java.io.Serializable {
> ...
> private java.lang.String _content = "";
> ...
> }
>
> On 10/14/05, Stephen Dennison <[EMAIL PROTECTED]> wrote:
> > I built from cvs, unless there's another branch (I checked out from
> > the head) it wasn't fixed for my issue.
> >
> > On 10/14/05, Ralf Joachim <[EMAIL PROTECTED]> wrote:
> > > Hi Stephen,
> > >
> > > some other users have pointed us to this problem before that had been
> > > included in the 0.9.9 release of castor. As far as I know this is fixed
> > > in CVS and we intend to build a new bugfix release till end of this
> > > month. You may want to have a look at issues 1152, 1153 and 1216 which
> > > had recently been resolved.
> > >
> > > Having said that we would appreciate if you could test the CVS version
> > > to verify if your problem is also fixed.
> > >
> > > Regards
> > > Ralf
> > >
> > >
> > > Stephen Dennison schrieb:
> > > > This was a tough one to explain, so if the following isn't clear, feel
> > > > free to ask me to elucidate further.
> > > >
> > > >
> > > > I have a schema that has a simpleType that contains an attribute that
> > > > has a ref to an attribute group. In castor 0.9.5.2 this resulted in
> > > > code being generated for the attribute as though it were a simpletype,
> > > > but in castor 0.9.9 it just calls the field an Object and doesn't
> > > > generate code for it.
> > > >
> > > >
> > > > Here's an example of the setup:
> > > > I have one schema that contains something like this:
> > > > ...
> > > > <xsd:attributeGroup name="someStuff">
> > > > <xsd:attribute ref="classification" use="required"/>
> > > > <xsd:attribute ref="markings" use="optional"/>
> > > > </xsd:attributeGroup>
> > > > <xsd:attribute name="classification>
> > > > <xsd:simpleType>
> > > > <xsd:restriction base="xsd:string">
> > > > <xsd:enumeration value="one"/>
> > > > <xsd:enumeration value="two"/>
> > > > <xsd:enumeration value="three"/>
> > > > </xsd:restriction>
> > > > </xsd:simpleType>
> > > > </xsd:attribute>
> > > > <xsd:attribute name="markings">
> > > > ...
> > > > </xsd:attribute>
> > > > ...
> > > >
> > > > And I have another schema that has something like this:
> > > > ...
> > > > <xsd:complexType name="someComplexType">
> > > > <xsd:attributeGroup ref="theCorrectNS:someStuff"/>
> > > > </xsd:complexType>
> > > > ...
> > > >
> > > > So, in the 0.9.5.2, A class was generated for
> > > > someComplextTypeSomeStuffType that would allow the values one, two, or
> > > > three where one was defined as a static
> > > > someComplextTypeStuffType("one"), two was a static
> > > > someComplextTypeStuffType("two"), etc. (not sure of the actual
> > > > case/capitalization here, but you get the idea)
> > > > This class was referenced by the someComplextType class. like this:
> > > > ...
> > > > public class someComplexType implements java.io.Serializable{
> > > > ...
> > > > someComplexTypeSomeStuff _classficiation;
> > > > ...
> > > > }
> > > >
> > > > In castor 0.9.9, the same class looks like this:
> > > > ...
> > > > public class someComplexType implements java.io.Serializable{
> > > > ...
> > > > java.lang.Object _classification;
> > > > ...
> > > > }
> > > >
> > > >
> > > > For now, I can get a compatible class generated if I make simpleTypes
> > > > that restrict base type xsd:string, name them what I expect should
> > > > have been generated, put my enumerated values in them, and manually
> > > > add all of the attributes to someComplexType. The problem with this
> > > > is that I have to locate every place where we are using an attribute
> > > > group and manually build the simple types by inspecting all of the
> > > > schemas that we include.
> > > >
> > > >
> > > >
> > > > So, is this a bug, or is there a setting somewhere that I don't know
> > > > about that I need to turn on, or a syntax fix that I need, in order to
> > > > get backwards-compatible classes generated?
> > > >
> > > > -------------------------------------------------
> > > > If you wish to unsubscribe from this list, please
> > > > send an empty message to the following address:
> > > >
> > > > [EMAIL PROTECTED]
> > > > -------------------------------------------------
> > >
> > > -------------------------------------------------
> > > If you wish to unsubscribe from this list, please
> > > send an empty message to the following address:
> > >
> > > [EMAIL PROTECTED]
> > > -------------------------------------------------
> > >
> > >
> >
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
