XML Polymorphism through inheritance?

[ian mayo]

Hi all,
I've got a DTD which I'm trying to tidy up and improve into an XSD - I'm battling with an area of object orientation which I'm used to in Java, but unsure about whether I can do it in XML:

I've got a container which currently contains a Choice element listing all of children it can contain. Whenever I add a new child I have to remember to extend this choice definition.

Since all of the children are extensions of a single base-type I was hoping that there would be some way of defining that my container just contains multiple instances of the base-type (or it's children). This type of thing seems quite normal in OOP, I just don't know if I'm asking too much of XSDs.

Cheers,
Ian

 

[C. M. Sperberg-McQueen]

Hi all,
I've got a DTD which I'm trying to tidy up and improve into an XSD - I'm battling with an area of object orientation which I'm used to in Java, but unsure about whether I can do it in XML:

I've got a container which currently contains a Choice element listing all of children it can contain. Whenever I add a new child I have to remember to extend this choice definition.

Since all of the children are extensions of a single base-type I was hoping that there would be some way of defining that my container just contains multiple instances of the base-type (or it's children). This type of thing seems quite normal in OOP, I just don't know if I'm asking too much of XSDs.

Yes. Define your container type as containing 1 occurrence (or however many you want) of top-level element foo, of type Foo.

Now for each of the possible kinds of children, specify that they are in the substitution group of element foo.

E.g. <xs:element name="bar" type="my:Foo" substitutionGroup="my:foo"/> <xs:element name="baz" type="my:Foo2" substitutionGroup="my:foo"/>

Constraints:
- the 'foo' element needs to be top-level, not local (so that other element declarations can point at it and say "That's my substitution-group head over there")
- the type of each child needs to be derived from type Foo (you mention that this is the case, so it shouldn't be a problem)

In some cases, you may wish to make the foo element itself abstract, so that it cannot be instantiated (so only my:bar and my:baz can occur, not my:foo).

I hope this helps.

-C. M. Sperberg-McQueen
World Wide Web Consortium

 

[ian mayo]

A thousand thank-you's Michael.

I can't admit to completely understading the answer, but now I know to investigate Substitution Groups in my O'Reilly XML Schema book - especially now I know it certainly is "do-able".

Thanks again,
Ian Mayo

 

[ian mayo]

Thanks again for that advice Michael.

It's worked fine for defining my structure to model "the real world".

Unfortunately my XML editor (XMLSpy) doesn't appear to be property recognising the model, but there's a strong chance that this is caused by my incorrect schema definition.

In the sample xsd (below) a scenario object can contain a ListA - which contains multiple instances of a Model (or child thereof). It can a ListB which includes instances of the same objects (defined using my "old" way of doing it).

My editor can see that into ListA I can but objects of type A or type B, but it isn't aware of their properties = whereas when I insert them into ListB - it provides direct access to their properties.

Is this because my schema definition is too vague to provide it with that information? Or is this in fact a problem with my XML editor?

Many thanks in advance,

Ian Mayo

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Ian Mayo (PlanetMayo Ltd) --> <!--W3C Schema generated by XMLSPY v5 rel. 4 U (http://www.xmlspy.com)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<xs:element name="Scenario">
<xs:annotation>
<xs:documentation>Container for a chain</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="ListA" type="ListTypeA"/> <xs:element name="ListB" type="ListTypeB"/> </xs:sequence> </xs:complexType> </xs:element>

<xs:complexType name="ListTypeA">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Model" />
</xs:choice>
</xs:complexType>

<xs:complexType name="ListTypeB">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="A" type="TypeA"/>
<xs:element name="B" type="TypeB"/>
</xs:choice>
</xs:complexType>

<!-- -->
<!-- DECISION MODELS -->
<!-- -->
<xs:element name="Model" abstract="true"/>
<xs:complexType name="ModelType">
<xs:annotation>
<xs:documentation>Base type for models</xs:documentation> </xs:annotation> <xs:attribute name="Name" type="xs:string" use="required"/> </xs:complexType>

<xs:element name="A" type="TypeA" substitutionGroup="Model"/> <xs:complexType name="TypeA"> <xs:complexContent> <xs:extension base="ModelType"> <xs:attribute name="attA_A" type="xs:float" use="required"/> <xs:attribute name="attA_B" type="xs:float" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType>

<xs:element name="B" type="TypeB" substitutionGroup="Model"/>

<xs:complexType name="TypeB">
<xs:complexContent>
<xs:extension base="ModelType">
<xs:attribute name="attB_A" type="xs:string" use="required"/> <xs:attribute name="attB_B" type="xs:string" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema>

 

[Eric Sirois]

Hello Ian,

If you want to use the globally defined elements <A> and <B>, change the following content model

<xs:complexType name="ListTypeB">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="A" type="TypeA"/>
<xs:element name="B" type="TypeB"/>
</xs:choice>
</xs:complexType>

<xs:complexType name="ListTypeB">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="A" />
<xs:element ref="B" />
</xs:choice>
</xs:complexType>

There is a difference bettwen the two content models. The top defines and use local element <A> and <B>. They are not the same as the two global element defintion. Think of it as defining a local variable in a method with the same name as global variable in a class.

Kind regards,
Eric

 

[ian mayo]

Thanks for coming back to me on this Eric,

but my challenge is how to avoid having to specify in the schema that I am allowing objects of type A or type B, I just want to specify that elements of type Model (or members of that substitution group) can be inserted into the list.

This will prevent me having to remember to change the ListType definition when I add a new model type. In my sample, the ListB element works ok (and that has been the way I've always done it), I just want to move forward to specifying sub-elements using the ListB type definition.

Cheers,
Ian

 

[ian mayo]

"Ian Mayo" wrote:

Is this because my schema definition is too vague to provide it with that information? Or is this in fact a problem with my XML editor?

So, it's turned out to be a bug in the editor (or something that hasn't been implemented). Never mind, just have to keep looking. Here's what they said

Hi Ian,

this seems to be a bug (or hasn't been implemented). I haven't found any similar bugs in our bug database and have therefore now submitted this for our developers to take a look at. As a general rule of thumb major bugs i.e. crashes are fixed first and then bugs are prioritized according to how often they have been reported by different customers. Unfortunately I can't give you a timeframe for a fix . Please excuse us for any inconveniences incurred..

Best Regards,

...