W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2002

Re: Substitution groups: Is the "or" in "restriction or extension " ex clusive?

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 11 Jan 2002 14:09:47 +0000
Message-ID: <58365541320.20020111140947@jenitennison.com>
To: Mark Feblowitz <mfeblowitz@frictionless.com>
CC: "Xmlschema-Dev (E-mail)" <xmlschema-dev@w3.org>
Hi Mark,

> So, as I read this, as long as each step (DD derived from D derived
> from B) is a valid derivation, then it is ok for dd of type DD to be
> in the substitution group b of type B, regardless of whether all of
> the derivation steps use the same subset of {extension,
> restriction}. Is that correct?

Sort of. You can tell what kind of derivation you can do by looking at
the final attribute of the head element's declaration.

If it's "" then the type can be derived in several steps, any mixture
of extension and restriction.

If it's "restriction" then all the steps have to be extensions.

If it's "extension" then all the steps have to be restrictions.

If it's "restriction extension" or "extension restriction" then the
element's type must be the same as the head element's type.

> (BTW, I don't quite understand number 1 below - could you explain?).

I dunno if this helps at all, but you can think of the Type Derivation
OK (Complex) schema component constraint as a function that's passed:

  - a derived type (D)
  - a base type (B)
  - a subset of keywords from the set {extension, restriction}

The call to this function is when you test whether a given element can
be part of a given substitution group. The values that are passed are:

  - the type of the element
  - the type of the head element of the prospective substitution group
  - the {substitution group exclusions} of the head element of the
    prospective substitution group (which come from the final

So point 1 of the constraint:
> 1 If B and D are not the same type definition, then the {derivation
> method} of D must not be in the subset.

means that if the type of the element is not the same type as the type
of the head element of the substitution group, then it must not have
been derived by any of the methods that aren't allowed according to
the {substitution group exclusions} of the head element.

Point 2 is the recursive call to make sure that D is validly derived
from B, taking into account the {substitution group exclusions}.

Does that make sense?



Jeni Tennison
Received on Friday, 11 January 2002 09:09:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:54 UTC