W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2002

Re: some problems regarding to transforming UML to XML Schema

From: Eddie Robertsson <eddie@allette.com.au>
Date: Tue, 15 Jan 2002 10:31:41 +1100
Message-ID: <3C436A5D.B45EB40B@allette.com.au>
To: xiaofeng.wang@ps.ge.com
CC: xmlschema-dev@w3.org
> Hello everybody:
> I found a hard time to map inheritance defined in UML to XML Schema.
> Usually, the complex type extension is used for inheritance. Then, two
> issues raised:

I think there are many who's been trying to fit XML to fit in with UML but from
what I have read on the mailing lists this is not an easy mapping to make. I was
going to suggest Dave Carlson's work but I see that you already have a link to
his work. Maybe someone else have more links for you?

> (1) Use <sequence> or <all> ?
> <sequence> specify the order of elements defined in it. But in UML, there is
> no such specification for order. Attributes and associations defined in a
> class may appear in any order. It seems <all> is good choice (??)

I guess the <all> group would be the best choice but as you have found out it
does have it's limitations. Especially when it comes to using the <all> group in
an extension. See below.

> (2) How to use <all>
> <all> does provide the flexibility for order. But it has other restrictions.
> It seems hard for me to handle multi-level inheritance defined in UML.
> Reference [1] shows an example for mapping Inheritance defined in UML to XML
> Schema. It looks like:
>         <xsd:element name = "Address" type = "Address" abstract = "true"/>
>         <xsd:complexType name = "Address" abstract = "true">
>                 <xsd:all>
>                         <xsd:element name = "name" type = "xsd:string"/>
>                         <xsd:element name = "street" type = "xsd:string"/>
>                         <xsd:element name = "city" type = "xsd:string"/>
>                 </xsd:all>
>         </xsd:complexType>
>         <xsd:element name = "USAddress" type = "USAddress" substitutionGroup
> = "Address"/>
>         <xsd:complexType name = "USAddress">
>                 <xsd:complexContent>
>                         <xsd:extension base = "Address">
>                                 <xsd:all>
>                                         <xsd:element name = "state" type =
> "xsd:string"/>
>                                         <xsd:element name = "zip" type =
> "xsd:positiveInteger"/>
>                                 </xsd:all>
>                         </xsd:extension>
>                 </xsd:complexContent>
>         </xsd:complexType>
> This schema can't pass the validation check, and the error is "groups are
> not allowed in ALL element".

The problem with the <all> group is that it must be the only child of the
complexType declaration and it can't have nested <all>, <choice> or <sequence>
groups. This means that you can never use an <all> group in a base type that
should be derived by extension. The reason for this is that when you create type
derived by extension it will be expanded to be a <sequence> of the base particle
and the particle defined in the extension. For example:

<xs:complexType name="base">
      <xs:element name="a1"/>
      <xs:element name="a2"/>
<xs:complexType name="derived">
      <xs:element name="a1"/>

The derived type will be expanded to the following:

<xs:complexType name="derived">
         <xs:element name="a1"/>
         <xs:element name="a2"/>
         <xs:element name="a1"/>

Which is now allowed by the recommendation since the <all> group is no longer
the only child of the complexType element.

> But if I change the <all> defined in the base complex type to <sequence>, it
> passed the validation check without any error. Could anybody please explain
> this?

What validator are you using? It seems it has a bug because this shouldn't be
allowed either for the same reasons as given above. A basic rule is that the
<all> group can never be used in a derivation by extension.

Received on Monday, 14 January 2002 18:23:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:54 UTC