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

 

[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>

to:

<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