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

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

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #8 from Michael Kay <mike@saxonica.com> ---

I am tasked with writing tests that relate to the changes made to the
specification in relation to bugs 10065 and 10207, which concern the details of
how membership of substitution groups is defined in relation to the
schema-element() type test. So I've been re-reading these complex bug reports,
and the current text of the specification.

As far as I can see, most of the problems addressed during the discussion of
bug 10207 are not resolved in the current draft. In some ways, the wording is
worse than it ever was. The first rule in 2.5.5.4 now reads:

1. The name of the candidate node matches the specified ElementName, or it
matches the name of an element in a substitution group headed by an element
named ElementName and the substituted element is not abstract. Call this
element the substituted element.

I read this as saying that the substituted element is the substituted element.
But even after resolving that, it's all wrong. The members of a substitution
group are not elements, but element declarations. It is element declarations
that are abstract, not elements. And despite the discussion on the bug report,
there is no clarity about which of the two element [declarations] we call the
"substituted" element [declaration] - given that A is substituting for B, I
think we are using "substituted" to refer to A, when it would be more logical
to call that the substituting element and B the substituted one.

There has been no clarification about what we mean by an element [declaration]
being "in a substitution group" despite all the discussion about whether we
meant actual membership or potential membership; there is no mention of the
decision we made that membership is affected by block/final (in other words
that we are talking about actual membership).

Given the way the rule is punctuated, most readers would parse it as (A or (B
and C)); but Oliver originally proposed adding the rule about the element being
abstract as a separate fourth rule, which implies that the correct parse is ((A
or B) and C). In any case, the editorial change applied to the proposal as
agreed has introduced an ambiguity.

Compounding the problem, the example below the rules has not changed since 1.0.
It talks about whether "customer" (the head of the substitution group) is
nillable, whereas the intent of the change is that we are concerned with
whether the relevant member of the substitution group is nillable.

In the case where substitution groups are not involved ("The name of the
candidate node matches the specified ElementName"), we don't seem to define a
meaning for the term "substituted element", and yet the term is used in the
following two rules which apply equally to this case.

I think the following wording would better reflect the agreed resolution of the
bug:

A SchemaElementTest matches a candidate element node if all of the following
conditions are satisfied:

1. Either:

1a. The name N of the candidate node matches the specified ElementName, or

1b. The name N of the candidate node matches the name of an element declaration
that is a member of the actual substitution group headed by the declaration of
element ElementName.

NOTE: the term "actual substitution group" is defined in [XSD]. The actual
substitution group of an element declaration H includes those element
declarations P that are declared to have H as their direct or indirect
substitution group head, provided that P is not declared as abstract, and that
P is validly substitutable for H, which means that there must be no blocking
constraints that prevent substitution.

2. The schema element declaration named N is not abstract.

3. derives-from( AT, ET ) is true, where AT is the type annotation of the
candidate node and ET is the schema type declared in the schema element
declaration named N.

4. If the schema element declaration named N is not nillable, then the nilled
property of the candidate node is false.

Example: The SchemaElementTest schema-element(customer) matches a candidate
element node in the following two situations:

(a) customer is a top-level element declaration in the in-scope element
declarations; the name of the candidate node is customer; the element
declaration of customer is not abstract; the type annotation of the candidate
node is the same as or derived from the schema type declared in the customer
element declaration; and either the candidate node is not nilled, or customer
is declared to be nillable.

(b) customer is a top-level element declaration in the in-scope element
declarations; the name of the candidate node is client; client is an actual
(non-abstract and non-blocked) member of the substitution group of customer;
the type annotation of the candidate node is the same as or derived from the
schema type declared for the client element; and either the candidate node is
not nilled, or client is declared to be nillable.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.