- From: Curt Arnold <curta@hyprotech.com>
- Date: Sat, 2 Dec 2000 11:28:27 -0600
- To: <xmlschema-dev@w3.org>
- Cc: <www-xml-schema-comments@w3.org>
I started writing this as a quick response to Roger's question on the xmlschema-dev list (http://lists.w3.org/Archives/Public/xmlschema-dev/2000Dec/0012.html) (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="http://www.example.org/train" targetNamespace="http://www.example.org/train" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"> <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. 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.
Received on Saturday, 2 December 2000 12:27:59 UTC