W3C home > Mailing lists > Public > xmlschema-dev@w3.org > December 2001

Re: extension and restriction

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 5 Dec 2001 17:40:15 +0000
Message-ID: <4098648929.20011205174015@jenitennison.com>
To: Niko Suave <niko@alum.mit.edu>
CC: xmlschema-dev@w3.org
Hi Niko,

> Hmm, that part of my e-mail didn't make as much sense the second time
> I read it.  I see what you mean about the above example being illegal.
> I think what I intended was to use restriction than extension like so:
>
> <xs:complexType name="base">
>   <xs:attribute name="name" type="xs:string"/>
>   <xs:attribute name="dead" type="xs:boolean"/>
>   <xs:anyAttribute namespace="##other" />
> </xs:complexType>
>
> <xs:complexType name="restriction">
>   <xs:complexContent>
>     <xs:restriction base="base">
>       <xs:attribute name="xlink:href" type="xs:anyURI"
>                     use="prohibited" />
>     </xs:restriction>
>   </xs:complexContent>
> </xs:complexType>
>
> Clearly, for 'base' xlink:href is allowed.
>
> For 'restriction,' it seems like xlink:href would also be allowed
> even though its prohibited because prohibition merely removes it
> from the attribute use set. Since it was never in there in the first
> place, this has no effect. Meanwhile, the wildcard "anyAttribute"
> makes xlink attributes okay.

I don't think that anyAttribute wildcards get passed through when you
derive by restriction.

In the above complex type, the restriction complex type's {attribute
wildcard} is set according to the following rules:

  [Definition:] Let the local wildcard be defined as the appropriate
  case among the following:

  1 If there is an <anyAttribute> present, then a wildcard based on
    the ·actual value·s of the namespace and processContents
    [attributes] and the <annotation> [children], exactly as for the
    wildcard corresponding to an <any> element as set out in XML
    Representation of Wildcard Schema Components (§3.10.2);

  2 otherwise ·absent·.

In the above case, there's no anyAttribute in the complex type, so the
local wildcard is absent.

  [Definition:] Let the complete wildcard be defined as the
  appropriate case among the following:

  1 If there are no <attributeGroup> [children] corresponding to
    attribute groups with non-·absent· {attribute wildcard}s, then the
    ·local wildcard·.

In the above case, there are no attributeGroup children within the
complexContent, so the complete wildcard is the local wildcard (i.e.
absent).

  The value is then determined by the appropriate case among the following:

  1 If the <restriction> alternative is chosen, then the ·complete
    wildcard·;

In the above case, the restriction alternative is the one that's being
used, so the {attribute wildcard} is the complete wildcard, i.e.
absent.

In other words, if you derive by restriction from a type that contains
an anyAttribute wildcard, then to maintain that anyAttribute wildcard
you must specify the anyAttribute within the restriction.

> I guess the deeper point I am driving it is that it seems like
> wildcards and attribute uses (as well as element rules etc) are
> completely independent systems which do not interact when verifying
> content. My understanding is that first the schema checks a given
> attribute against the attribute use, and then against the wildcard.
> If either says it is okay, then it is. Is that reasonable? I assume
> the same holds true for element content, to some degree. Basically,
> another way to say this is that the attribute uses cannot specify
> what CANNOT be there, only what can. Is this correct?

Yes, I think so. So for example, you can't say "any attribute in the
XLink namespace aside from xlink:href".

For interest, you could do this in RELAX NG with:

  <attribute>
    <nsName ns="http://www.w3.org/1999/xlink">
      <except>
        <name>xlink:href</name>
      </except>
    </nsName>
    <text />
  </attribute>

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Wednesday, 5 December 2001 12:42:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:25 GMT