W3C home > Mailing lists > Public > xmlschema-dev@w3.org > July 2004

Re: Rearraging order of elements in a sequence.

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 15 Jul 2004 15:16:46 +0100
Message-ID: <1176229725.20040715151646@jenitennison.com>
To: Eric Sirois <easirois@rogers.com>
Cc: xmlschema-dev@w3.org

Hi Eric,

> The second test was to use restriction to clear the all the elements
> in the restriction and then add them back in the right order in
> using extension. In this case XSV and Saxonica seem to like this
> arrangement returning no errors, but Xerces returns the same
> particle is not the same as the base error and also an extra error
> stating that the base content model is not emptiable. Which is
> correct as per the spec?

I think that Xerces (and MSXML, FWIW) is correct here, and XSV and
Saxonica wrong. When you do a restriction, you can't empty a content
model unless it's emptiable (all the particles are optional). Your
original content model is:

  (a, b?, d*)

And this says that the <a> element must appear. Any restriction of
your original complex type must include an <a> particle. It would be
valid, however, to restrict it to:

  (a, b?)

and then base the extension on this. Try:

<xs:complexType name="dumpElements">
  <xs:complexContent>
    <xs:restriction base="rootType">
      <xs:sequence>
        <xs:element ref="a" />
        <xs:element ref="b" minOccurs="0" />        
      </xs:sequence>
      <xs:attribute name="test" />
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

<xs:complexType name="addSequence">
  <xs:complexContent>
    <xs:extension base="dumpElements">
        <xs:sequence>
          <xs:element ref="c" />
          <xs:element ref="d" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

Note that the only reason you can do this rearrangement is that <d> is
optional in the original content model.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Thursday, 15 July 2004 10:16:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:10 UTC