[Bug 5074] substitution groups not that strictly limited

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5074


cmsmcq@w3.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Status Whiteboard|thimble, easy               |thimble, work, clarification
                   |                            |cluster




------- Comment #3 from cmsmcq@w3.org  2008-01-03 04:52 -------
I believe the schema you provide is valid, but as written it doesn't test 
whether types of elements in the substitution group can be derived indirectly 
from the head of the substitution group, because types are not given on the 
element declarations for e0 or eb.  They default, therefore, to type ta.  (The 
form in which I tested it differs slightly from the one in comment #2; it's on 
the Web at 
http://www.w3.org/XML/2008/xsdl-exx/sgd1.xsd if you wish to inspect it.)

A modified form of the example (http://www.w3.org/XML/2008/xsdl-exx/sgd2.xsd)
with explicit association of types t0 and tb with elements e0 and eb is also
valid, conforming, and correct, as far as I can tell. 

I've tested these two schemas with some instance documents (in the same
directory), with varying results.  

  - libxml / xmllint does not complain about the schema, but it rejects 
    most of the test instances; I wonder if substitution
    groups have not yet been implemented.  
  - MSV rejects schema sgd1.xsd, with the message 'Unimplemented feature: 
    "omitting type attribute in <element> element with substitutionGroup 
    attribute"'.
  - Saxon, Xerces C, and Xerces J all accept the schema and pronounce the 
    test instances valid or invalid in a way consistent with the type 
    definitions.

I believe these implementations are taking the rule in question to mean
that if the head of a substitution group has declared type T, then each 
element in the substitution group must have a declared type derived from
T (subject to the blocks and exclusions and whatnot).  That is, I think they
are not interpreting the rule as meaning the types of member elements must
be derived either exclusively by a series of restriction steps, or exclusively
by a series of extension steps.

Speaking for myself, I think the implementations' interpretation makes sense;
at least, it matches what I always thought the spec meant to say.  But you
have made me aware that the wording can bear a rather different interpretation;
I think both that the 1.1 text should be revised and that an erratum should
be issued for 1.0.

Received on Thursday, 3 January 2008 04:52:36 UTC