[Bug 10207] [XPath] Matching abstract schema-element tests

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





--- Comment #4 from Oliver Hallam <oliver@cbcl.co.uk>  2010-07-20 16:53:08 ---
After looking closer at the definition of substitution group, I think we
already require using "block" and "final" (and all the complexity it adds).  

The sentence said:

1. The name of the candidate node matches the specified ElementName or matches
the name of an element in a substitution group headed by an element named
ElementName.

If we look at the definition of substitution group:

Definition: Substitution groups are defined in [XML Schema] Part 1, Section
2.2.2.2. Informally, the substitution group headed by a given element (called
the head element) consists of the set of elements that can be substituted for
the head element without affecting the outcome of schema validation.]

Section 2.2.2.2 specifies:

Note that element substitution groups are not represented as separate
components. They are specified in the property values for element declarations
(see Element Declarations (§3.3)).

And Element Declarations defines the substitution group as (3.3.6.4):

[Definition:]  One element declaration is substitutable for another if together
they satisfy constraint Substitution Group OK (Transitive) (§3.3.6.3).

[Definition:]   Every element declaration (call this HEAD) in the {element
declarations} of a schema defines a substitution group, a subset of those
{element declarations}. An element declaration is in the substitution group of
HEAD if and only if it is ·substitutable· for HEAD.

So finally we reach Section 3.3.6.3 to define what can substitute for a head
element:

Schema Component Constraint: Substitution Group OK (Transitive)
For an element declaration (call it M, for member) to be substitutable for
another element declaration (call it H, for head) at least one of the following
must be true:
1 M and H are the same element declaration.
2 All of the following are true:
2.1 H. {disallowed substitutions} does not contain substitution.
2.2 There is a chain of {substitution group affiliations} properties from M to
H, that is, either M.{substitution group affiliations} contains H, or
M.{substitution group affiliations} contains a declaration whose {substitution
group affiliations} contains H, or . . .
2.3 The set of all {derivation method}s involved in the ·derivation· of M.{type
definition} from H.{type definition} does not intersect with the union of (1)
H.{disallowed substitutions}, (2) H.{type definition}.{prohibited
substitutions} (if H.{type definition} is complex, otherwise the empty set),
and (3) the {prohibited substitutions} (respectively the empty set) of any
intermediate declared {type definition}s in the ·derivation· of M.{type
definition} from H.{type definition}.

This definition already involves H.{disallowed substitutions} and so I believe
that the block attribute must already be taken into account.

I believe that the final attribute does not make a difference here - It is only
used to enforce Schema Component Constraint: Element Declaration Properties
Correct (3.3.6.1).

We already require these attributes to be handled, and hence all the messiness
that that entails.  I believe that the change suggested is sufficient.



A minor simplification:

I believe

1. The name of the candidate node matches the specified ElementName or matches
the name of an element in a substitution group headed by an element named
ElementName.

is equivalent to

1. The name of the candidate node matches name of an element in a substitution
group headed by an element named ElementName.

as an element is always included in a substitution group headed by itself

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 20 July 2010 16:53:11 UTC