Hi Adam,

Just to add to Mike's reply: what you have to do in this situation is
use unioned paths that select all the directories and files, as
follows:

  <xs:key name="paths">
    <xs:selector xpath="directory | file"/>
    <xs:field xpath="@step"/>
  </xs:key>

Another problem with your current schema is that you've defined this
identity constraint on the <node> element. Identity constraints only
apply to the element on which  you define them -- unlike types, they
aren't inherited via the substitution group hierarchy. You never have
any <node> elements in your document (since they're abstract), so the
key will never come into play. The identity constraints should
probably be defined on the <directory> element instead.

Also, I'm not sure what constraint you actually want to test here.
Currently you're testing that, within one particular <node>, no
*child* <directory> or <file> has the same step as any other. Do you
want to make sure that in the document *as a whole* there aren't any
directories or files with the same value for their step attributes? If
so, then rather than defining the identity constraint on the <node>
element, you should define it on the <directory> element (since that's
your document element) and define the key over all the descendant (not
just children) <directory> and <file> elements:

  <xs:key name="paths">
    <xs:selector xpath=".//directory | .//file"/>
    <xs:field xpath="@step"/>
  </xs:key>

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

The rules governing legal restrictions are really complicated,
especially when you start factoring in substitution groups and
wildcards. The element particle for <node> is replaced with a choice
between the members of the substitution groups. Xerces seems to be
objecting to the way that choice gets restricted (MSXML is happy with
it). I found that doing:

  <xs:complexType name="LeafType">
    <xs:complexContent>
      <xs:restriction base="NodeType">
        <xs:sequence>
          <xs:element ref="title" minOccurs="0" maxOccurs="unbounded"/>
          <xs:choice minOccurs="0" />
        </xs:sequence>
        <xs:attribute name="step" type="xs:NMTOKEN"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

Fixed the problem. (The minOccurs="0" on the empty <xs:choice> is only
necessary if you want it to work in MSXML as well.)

Alternatively, you could reverse the hierarchy like this:

<xs:complexType name="LeafType">
  <xs:sequence>
    <xs:element ref="title" minOccurs="0" maxOccurs="unbounded" />
  </xs:sequence>
  <xs:attribute name="step" type="xs:NMTOKEN" />
</xs:complexType>

<xs:complexType name="NodeType">
  <xs:complexContent>
    <xs:extension base="LeafType">
      <xs:sequence>
        <xs:element ref="node" minOccurs="0" maxOccurs="unbounded" />
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

Finally, another thing I noticed in your schema. You have:

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

The <xs:attribute> here isn't doing what you think it's doing.
use="prohibited" means that, in this restriction, the previously
optional attribute is no longer allowed: it's a mechanism for
excluding attributes that are otherwise inherited when you derive a
type by restriction.

Without the use="prohibited", the <xs:attribute> would mean that if an
element of the type Label had a role attribute, it would have to
have the value 'label', and if it didn't then a role attribute would
be added to it in the PSVI.

But with the use="prohibited", you're saying that the elements of type
Label don't have role attributes at all. Importantly, this means that
you won't get the role attributes added in the PSVI. So the
fixed="label" does nothing here.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

From rschloss@u...  Tue Jul 20 10:30:18 2004
Return-Path: <rschloss@u...>
X-Original-To: xmlschema-dev@l...
Delivered-To: xmlsch