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

RE: Help: transforming "sequence" into "all" content model.

From: Emer Magnani <Emer.Magnani@di3.co.uk>
Date: Tue, 14 May 2002 14:10:01 -0400 (EDT)
Message-ID: <8BE4A2E53E90D3119D1500E018C1F53A3DFDC2@charlie.diexe.co.uk>
To: "'Eric van der Vlist'" <vdv@dyomedea.com>
Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Thanks Eric.  I used the "choice" content model, as you described in your
email (below).  This approach seems to 
be very flexible when the structure of the markup cannot be changed.

Thanks again,
Emer.

-----Original Message-----
From: Eric van der Vlist [mailto:vdv@dyomedea.com]
Sent: 11 May 2002 23:02
To: Emer Magnani
Cc: 'xmlschema-dev@w3.org'
Subject: Re: Help: transforming "sequence" into "all" content model.


Hi,

On Wed, 2002-05-08 at 11:41, Emer Magnani wrote:
> Hi,
> 
> I have an xml schema that defines elements using the "sequence" content
> model.  I am trying to modify the schema so that it allows child elements
to
> appear in any order.  Here is sample element:
> 
code snipped.
> 
> Looking at the definition of the "all" content model, it appears to me
that
> the "all" content model cannot be used to express such a hierarchical
> structure.  Is there any work around?

Yes, there are *some* workarounds which are not generic but may help is
some cases.

First, if you can (and accept to) change the structure of your markup,
you can add a container to make your structure fit into the xs:all mold:

<myNode>
  <propertyA/>
  <propertyB/>
  <subNodes>
    <myNode>...
  </subNodes>
</myNode>

would do the trick.

Alternatively, in your case, transforming propertyA and propertyB into
attributes would also allow to specify your content model with a
xs:choice.

Now, if you can't (or don't want to) change the structure of the
instance documents, the closest you can get to your document is through
using xs:choice:

<xs:element name="myNode>
  <xs:complexType>
    <xs:choice minOccurs="0" maxOccurs="0">
      <xs:element ref="propertyA"/>
      <xs:element ref="propertyB"/>
      <xs:element ref="myNode"/>
    </xs:choice>
  </xs:complexType>
</xs:element>

By doing so, you loose the constraint on propertyA and B occuring at
most one time. You can express this adding a constraint using a rule
based schema language such as schematron, but you may also have a
workaround hacking a xs:unique constraint and if you write:

<xs:element name="myNode>
  <xs:complexType>
    <xs:choice minOccurs="0" maxOccurs="0">
      <xs:element ref="propertyA"/>
      <xs:element ref="propertyB"/>
      <xs:element ref="myNode"/>
    </xs:choice>
  </xs:complexType>
  <xs:unique name="checkPropertyA">
    <xs:selector xpath=".">
    <xs:field xpath="propertyA">
  </xs:unique>
</xs:element>

There would be a violation of the xs:unique rule if the path identified
by xs:field had more than one occurrence for an occurrence of the path
identified by the xs:selector (ie in clear if there was more than one
propertyA element.

Note that the error messsage in this case will probably be very
confusing for a end user :-) ...

Hope this helps.

Eric

-- 
See you in Barcelona.
                              http://www.xmleurope.com/2002/schedule.asp
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------
Received on Tuesday, 14 May 2002 19:45:55 UTC

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