Re: Out of band attributes

Hi Nathan,

> Does that apply when using the <anyAttribute>, as well? I'm not
> exactly clear on what you meant. Also, I've never used the
> <anyAttribute>, so I'm still a little hazy on how that works.

The "latter" that Henry and I were talking about was about using
xs:anyAttribute.

xs:anyAttribute is a wildcard that allows elements of the relevant
complex type to take any attribute provided it meets the criteria of
the namespace attribute on xs:anyAttribute. For example:

  <xs:anyAttribute namespace="##targetNamespace" />

means that elements of that type can have any attribute provided that
it is in the target namespace of the schema.

When the schema validator comes across an element of the relevant
type, it looks at each attribute in turn. If there's no attribute
declaration for the relevant attribute, then the schema validator
checks to see whether it complies with the namespace requirements
stated on the attribute wildcard.

By default, the schema validator also tries to find a global attribute
declaration for the attribute; if it can't find one, then the
attribute is invalid. You can change this behaviour by changing the
processContents attribute, which works in exactly the same way as for
the xs:any wildcard (i.e. skip doesn't validate, lax validates if it
can). But as Henry said, this helps because it means that any globally
defined attribute (in the correct namespace) is automatically
acceptable on the element - you don't have to worry about changing the
content type, just about adding the attribute.

When you derive a type by restriction, the general rule is that unless
something is specified in the derived type, it isn't allowed in the
derived type. This rule applies to element content and attribute
wildcards, but it doesn't apply to attributes. So for example if you
have the base type:

<xs:complexType name="baseType">
  <xs:sequence>
    <xs:element ref="foo" />
    <xs:element ref="bar" minOccurs="0" />
  </xs:sequence>
  <xs:attribute ref="baz" />
  <xs:anyAttribute namespace="##other" />
</xs:complexType>

and the derived type:

<xs:complexType name="restrictedType">
  <xs:complexContent>
    <xs:restriction base="baseType">
      <xs:sequence>
        <xs:element ref="foo" />
      </xs:sequence>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

then the effective type is:

<xs:complexType name="restrictedType">
  <xs:sequence>
    <xs:element ref="foo" />
  </xs:sequence>
  <xs:attribute ref="baz" />
</xs:complexType>

The content model gets overridden, the attribute gets inherited, and
the attribute wildcard gets dropped.

So to make sure that a derived type still has the attribute wildcard,
you have to explicitly include it on that derived type; of course you
could add further restrictions by changing the namespace attribute in
the derived type definition:

<xs:complexType name="restrictedType">
  <xs:complexContent>
    <xs:restriction base="baseType">
      <xs:sequence>
        <xs:element ref="foo" />
      </xs:sequence>
      <xs:anyAttribute namespace="http://www.w3.org/1999/xlink" />
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

Cheers,

Jeni

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

Received on Friday, 8 March 2002 09:32:32 UTC