RE: Confirmation needed: block attribute

Hi Jeni,

Oops - you're right, I misinterpreted the question.  Now that you have
clarified it, I agree with your reading of the rec.  I don't think this
result is what most schema authors would expect, though.

Priscilla
------------------------------------------------------------------
Priscilla Walmsley                          priscilla@walmsley.com
Vitria Technology                            http://www.vitria.com
Author, Definitive XML Schema                  (Prentice Hall PTR)
------------------------------------------------------------------

> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org]On Behalf Of Jeni Tennison
> Sent: Thursday, February 14, 2002 12:50 PM
> To: Priscilla Walmsley
> Cc: Eric van der Vlist; xmlschema-dev@w3.org
> Subject: Re: Confirmation needed: block attribute
>
>
> Hi Priscilla,
>
> >> If I specify an empty string in the element definition and
> nothing in
> >> the type definition, the actual value for the element will
> be "", the
> >> actual value for the type definition will be the default one (thus
> >> "restriction") and the result will still be "restriction". Can you
> >> confirm this (since I find if rather confusing) ?
> >
> > No, the empty set is different from the attribute being absent. In
> > this case, there would be no disallowed substitutions.
>
> I believe that Eric was talking about how this combines with the
> prohibited substitutions from the element's complex type. I think that
> he was highlighting the situation where you have:
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>            block="restriction">
>
> <xs:element name="foo" type="fooType" block="" />
> <xs:complexType name="fooType" />
>
> <xs:element name="bar" substitutionGroup="foo">
>   <xs:complexType>
>     <xs:restriction base="fooType" />
>   </xs:complexType>
> </xs:element>
>
> </xs:schema>
>
> Here, the prohibited substitutions for the fooType is the set
> containing the keyword 'restriction'.
>
> This means that, while the element makes no restrictions on what it
> can be substituted with, the element's complex type *does* place a
> constraint on the allowed substitutions. Specifically, it means that
> the foo element cannot be substituted by the bar element, since the
> bar element's type is a restriction of the foo element's type.
>
> At least this is my interpretation of Schema Component Constraint:
> Substitution Group OK (Transitive):
>
>   For an element declaration (call it D) together with a blocking
>   constraint (a subset of {substitution, extension, restriction}, the
>   value of a {disallowed substitutions}) to be validly substitutable
>   for another element declaration (call it C) all of the following
>   must be true:
>
>   1 The blocking constraint does not contain substitution.
>
>   2 There is a chain of {substitution group affiliation}s from D to
>     C, that is, either D's {substitution group affiliation} is C, or
>     D's {substitution group affiliation}'s {substitution group
>     affiliation} is C, or . . .
>
>   3 The set of all {derivation method}s involved in the derivation
>     of D's {type definition} from C's {type definition} does not
>     intersect with the union of the blocking constraint, C's
>     {prohibited substitutions} (if C is complex, otherwise the empty
>     set) and the {prohibited substitutions} (respectively the empty
>     set) of any intermediate {type definition}s in the derivation of
>     D's {type definition} from C's {type definition}.
>
>             http://www.w3.org/TR/xmlschema-1/#cos-equiv-derived-ok-rec
>
> Cheers,
>
> Jeni
>
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>
>

Received on Thursday, 14 February 2002 13:51:29 UTC