Altova Mailing List Archives


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

From: Jeni Tennison <jeni@------------.--->
To: Mark Feblowitz <mfeblowitz@------------.--->
Date: 1/11/2002 2:10:00 PM
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
    attribute)

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?

Cheers,

Jeni

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

From xmlschema-dev-request@t...  Fri Jan 11 09:12:29 2002
Received: from tux.w3.org

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.