Re: Meaning of block="substitution"?

"Curt Arnold" <> writes:

> I started writing this as a quick response to Roger's question on the
> xmlschema-dev list
> ( (he
> has a course to teach the next two days of course), but on a cursory check
> of the schema draft, it doesn't follow what it would have expected.  I
> haven't had a chance to research this fully,  maybe I haven't worked out all
> the details.
> ---   from the hip answer to Roger's question -----
> I think that you would typically (possibly exclusively) use block on a
> reference (not a definition) of an element.  A substitution group target
> must be an immediate child of <schema> (not a locally defined element).
> You'll have to really did into the schema draft to see under what conditions
> block is allowed, but in some ways it should follow similar rules to
> minOccurs and maxOccurs (which make sense in the context of a complexType
> definition, but doesn't make sense for a global definition).
> If you are able to use a block attribute on a global definition, it is
> possible that a reference in a particular complexType would change it.
> <xsd:schema xmlns=""
> targetNamespace=""
> xmlns:xsd="">
>     <xsd:element name="subway" type="xsd:string" block="substitution"/>
>     <xsd:element name="train" substitutionGroup="subway" type="xsd:string"/>
>     <xsd:element name="notrains">
>         <xsd:complexType>
>             <xsd:element ref="subway" block="substitution"/>
>         </xsd:complexType>
>     </xsd:element>
>     <xsd:element name="anything">
>         <xsd:complexType ref="subway" block=""/>
>     </xsd:element>
> </xsd:schema>
> -------- End of naive answer --------------
> So I went to check the schema draft to see if I got things right and found a
> few things that seemed counter-intuitive.
> Section 4.3.2
> Schema Representation Constraint: Element Declaration Representation OK
> 1.3  If the item's parent is not schema, then 1.3.1  One of ref or name must
> be present, but not both;
> 1.3.2  If ref is present, then all of complexType, simpleType, key, keyref,
> unique, nullable, default, fixed, block and type must be absent, i.e. only
> minOccurs, maxOccurs, id are allowed in addition to ref, along with
> annotation;
> In section 1.3.2, I expected block to be allowed on a ref (and possibly
> prohibited if name was present).  What sense does block="substitution" make
> unless it can be applied to a reference to an examplar.  If it has to appear
> or an element reference, the only thing is does is dispute another element's
> attempt to use it as an examplar.

It does make sense to put it on a global declaration, but not much, I
admit.  We removed it from refs, where I agree it makes more sense.

This is a reduction in functionality from April to September, in
response to a deeper problem with the uniqueness of (global)
declarations.  In due course, but probably not until 1.1, we'll bring
this back.

> Disallowing default, fixed, and nullable on references is also questionable
> (but off topic)


> The schema for schema does not appear to allow block="" or block="none" (to
> negate a blockDefault="substitution") though the description for disallowed
> substitutions implies that a value that normalized to an empty string would
> be acceptible.  It would seem useful that if you could set a strict value
> for blockDefault (and it probably goes for fixedDefault too) that you should
> be able to override it with a more permissive value.

Um, It does allow block="", since both 'block' attributes are declared 
as union types over '#all' and a list type, and lists can always be
empty (unless constrained not to be, which these aren't).

  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail:

Received on Friday, 5 January 2001 09:46:07 UTC