Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Unique and Substitution groups

From: Adam van den Hoven <avandenhoven@-----.--->
To: XML Schema Development <xmlschema-dev@--.--->
Date: 7/19/2004 8:44:00 AM
I trust all of you are having as pleasantly challenging a day as I am.

I'm writing a relatively complex Schema and this is going to be the first
time I am going to define any uniqueness checks. I'm also making extensive
use of abstract elements and substitution groups. Right now I'm not 100%
sure how those two behave together. I would like to think that they behave
as you would expect but I'm looking for confirmation.

The XML I'm writing the schema looks something like:

<directory step="home">
  <title>This is a Title</title>
  <label>This is a Label</label>
  <directory step="dir1">
    <title>Another Title</title>
    <file step="AFile">
      <title>File Title</title>
    </file>
  </directory>
</directory>

In this schema, I want to make both <directory> and <file> substitutions for
an abstract element, which we can call node. This is the schema I want to
apply  to this document:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:attribute name="role" type="xs:NMTOKEN"/>
  <xs:complexType name="Title" id="ComplexType.Title">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute ref="role" default="title"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="Label" id="ComplexType.Label">
    <xs:simpleContent>
      <xs:restriction base="Title">
        <xs:attribute ref="role" fixed="label" use="prohibited"/>
      </xs:restriction>
    </xs:simpleContent>
  </xs:complexType>
  <xs:element name="title" type="Title"/>
  <xs:element name="label" type="Label" substitutionGroup="title"/>
  <xs:element name="node" abstract="true" type="NodeType">
    <xs:key name="titlerole">
      <xs:selector xpath="title"/>
      <xs:field xpath="@role"/>
    </xs:key>
    <xs:key name="paths">
      <xs:selector xpath="node"/>
      <xs:field xpath="@step"/>
    </xs:key>
  </xs:element>
  <xs:complexType name="NodeType">
    <xs:sequence>
      <xs:element ref="title" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element ref="node" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="step" type="xs:NMTOKEN"/>
  </xs:complexType>
  <xs:complexType name="LeafType">
    <xs:complexContent>
      <xs:restriction base="NodeType">
        <xs:sequence>
          <xs:element ref="title" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="step" type="xs:NMTOKEN"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="directory" type="NodeType" substitutionGroup="node"/>
  <xs:element name="file" type="LeafType" substitutionGroup="node"/>
</xs:schema>

My original question was about the use of <xs:key> in this schema. Is it
enough to simply define the constraints on the abstract element and not
bother worrying about it for the substituting elements.

In preparing this example, I started getting exceptions on the LeafType
delcaration. Namely, I'm being told:

    cos-particle-restrict.2: Forbidden particle restriction:
'choice:all,sequence,elt'.
    derivation-ok-restriction.5.4.2: Error for type 'LeafType'.  The
particle of the type is not a valid restriction of the particle of the base.

Both errors refer to the LeafType complexType.

Any thoughts on either issue?
Adam

From mhk@m...  Mon Jul 19 19:09:39 2004
Return-Path: <mhk@m...>
X-Original-To: xmlschema-dev@l...
D


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent