- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: 27 Oct 2004 15:30:13 -0600
- To: W3C XML Schema Comments list <www-xml-schema-comments@w3.org>
- Message-Id: <1098912611.2579.363.camel@localhost>
I believe a careful reading of the spec shows that as currently
defined, schema-validity assessment is not possible for any schema +
element pair in which an element in the subtree dominated by the
validation root matches a 'skip' wildcard in the schema. If this is
so, I think it's a fairly serious bug.
A brief summary of the problem follows; after that brief summary, I
give a more detailed description of the problem and propose some
sample wording for a fix. A very detailed account of the problem in
the form of an informal validation trace is appended.
1 BRIEF SUMMARY
Consider a schema with an element declaration for 'sandbox', the type
for which is a single 'skip' wildcard with maxOccurs unbounded.
If in a document we have an element s1 which matches the element
declaration for 'sandbox', and an element p3 which is a child of s1,
then any attempt to validate element s1 leads us through the
validation rule Schema Validity Assessment (Element) of section 3.3.4
in Structures.
When applied to element s1, clause 2 of validation rule Schema
Validity Assessment (Element) requires among other things that the
schema-validity of all children be assessed using the same validation
rule, Schema Validity Assessment (Element). By our hypothesis, among
those children is element p3.
Rule Schema-Validity Assessment (Element) does not apply to elements
whose context-determined declaration is 'skip' and which lack an
xsi:type attribute. So we cannot validate p3, and thus cannot satisfy
clause 2 of our attempt to validate s1.
I believe the error here is that the rule Schema-Validity Assessment
(Element) should provide for elements whose context-determined
declaration is 'skip' but does not do so. (A side issue also arises
when the element has an xsi:type attribute, which relates to the
priority rule following Schema-Validity Assessment (Element), which I
commented on in a separate email today. When the rule is recast,
I believe the wording also needs to be changed to make clear that if
the context-determined declaration is 'skip', the element must not be
validated even if it has an xsi:type attribute. The behavior of XSV
and Xerces J suggests that their authors agree.)
2 FULLER DESCRIPTION
Consider a schema with an element declaration for 'sandbox', the type
for which is a single 'skip' wildcard with maxOccurs unbounded.
If in a document we have an element s1 which matches the element
declaration for 'sandbox', and an element p3 which is a child of s1,
then any attempt to validate element s1 leads us through the
validation rule Schema Validity Assessment (Element) of section 3.3.4
in Structures.
When applied to element s1, clause 2 of validation rule Schema
Validity Assessment (Element) requires among other things that the
schema-validity of all children be assessed using the same validation
rule, Schema Validity Assessment (Element). By our hypothesis, among
those children is element p3.
So to fulfill rule 3 of section 5.2, we must (among other things)
apply rule SVA(E) to element p3.
As shown in the detailed trace below, in the normal course of
validating element s1, element p3 will be assigned a so-called
'context-determined declaration' of 'skip'. It is with this
context-determined declaration that we are to validate element p3.
When applied to element p3, Schema Validity Assessment (Element) says
that both clause 1 and clause 2 must apply. Clause 1 says that either
clause 1.1 or clause 1.2 must be satisfied. Let us assume for the
moment that clause 1.2 (we have a type definition for the element)
does not apply. We'll come back to this possibility later.
Clause 1.1 says that both 1.1.1 and 1.1.2 must be satisfied. Clause
1.1.1 says we have an element declaration because one of 1.1.1.1
through 1.1.1.3 is true.
Clause 1.1.1.1 is not true in our case: we aren't starting with
element p3, so we have no processor-stipulated element declaration.
Clause 1.1.1.2 is not true in our case: we have a context-determined
declaration of 'skip', which is not a declaration (despite the
apparent meaning of the term 'context-determined declaration').
Clause 1.1.1.3 is true if (and only if) both 1.1.1.3.1 and 1.1.1.3.2
are true.
Clause 1.1.1.3.1 is true if and only if the context-determined
declaration of the element being validated is 'skip'. It is thus not
true in our case, since the context-determined declaration of element
p3 IS 'skip'.
Since 1.1.1.3.1 is not true, 1.1.1.3 is not true.
Since none of 1.1.1.1 through 1.1.1.3 is true, clause 1.1.1 is not
satisfied.
Since clause 1.1.1 is not satisfied, clause 1.1 is not satisfied.
Since neither clause 1.1 nor (by hypothesis) clause 1.2 is satisfied,
clause 1 cannot be satisfied.
Since clause 1 cannot be satisfied, the validation rule
Schema-Validity Assessment (Element) cannot be satisfied for element
p3.
If p3 is not assessed using Schema-Validity Assessment (Element), then
when Schema-Validity Assessment (Element) is applied to element s1,
clause 2 cannot be discharged.
Since clause 2 of Schema-Validity Assessment (Element) cannot be
discharged when we are validating element s1, we cannot successfully
perform schema-validity assessment on s1. The argument here
constructed for element s1 applies to any element whose descendants
include an element which matches a 'skip' wildcard.
3 POSSIBLE FIX
One possible rewording of the validation rule might be:
Validation Rule: Schema-Validity Assessment (Element)
The schema-validity assessment of an element information item
depends on its validation and the assessment of its element
information item children and associated attribute information
items, if any.
An element information item's schema-validity can be assessed in any
of the following ways.
1 Assessment may be performed using a given element declaration,
as described in Schema-Validity Assessment (Element, Element
Declaration) below, if and only if one of the following is true:
1.1 The processor has stipulated the element declaration to use
as part of starting a validation episode.
1.2 The element declaration was assigned to the element
information item as its context-determined declaration in the
course of assessing the validity of the element information
item's parent.
1.3 The context-determined declaration assigned to the element
information item is the keyword 'strict' or the keyword 'lax',
and the element information item's expanded name resolves to the
element declaration as defined by QName resolution (Instance)
(&sec;3.15.4).
It follows from the definition of context-determined declaration and
the rules governing the initiation of validation episodes that if
any of 1.1 through 1.3 apply, the other two do not.
Note that if the context-determined declaration of the element
information item is the keyword 'skip', then the schema-validity of
the element information item must not be assessed in this way.
2 Assessment may be performed using a given type definition, as
described in Schema-Validity Assessment (Element, Type) below, if
and only if clause 1 does not apply and one of the following is
true:
2.1 The processor has stipulated the type definition to use
as part of starting a validation episode.
2.2 The element information item has an xsi:type attribute
whose value is a valid QName, and that QName resolves to a
type definition, as defined in QName resolution (Instance)
(&sec;3.15.4); in this case, the type definition resolved to
is the one to be used in assessment.
2.3 Both of the previous conditions apply, i.e. the
processor has stipulated a type definition T1 to use, and
the element information item also has an xsi:type attribute
whose value resolves to a type definition T2.
In this case, if T1 is a complex type definition, then T2
MUST be validly derived from T1 given the {prohibited
substitutions} of T1, as defined in Type Derivation OK
(Complex) (&sec;3.4.6); if T1 is a simple type definition,
then T2 MUST be validly derived from T1 given the empty set,
as defined in Type Derivation OK (Simple) (&sec;3.14.6).
Note that conditions 2.1, 2.2, and 2.3 are not mutually exclusive.
The behavior of a conforming processor is thus strictly
non-deterministic, but processors SHOULD apply clause 2.3 if it
applies, rather than 2.1 or 2.2.
3 If the element information was assigned the keyword 'skip' as
its context-determined declaration during the validation of the
element information item's parent, then the schema-validity of
the element information item is unknown.
If and only if an element information item's schema-validity is
assessed as described in clauses 1 or 2, the element is said to have
been strictly assessed.
Validation Rule: Schema-Validity Assessment (Element, Element
Declaration)
The schema-validity of an element information item E has been
assessed against an element declaration D if and only if:
1 The element declaration D is not absent.
2 The local validity of E with respect to D has been evaluated
as described in Element Locally Valid (Element) (&sec;3.3.4).
3 The schema-validity of each element information items among
the [children] of E has been assessed as described in
Schema-Validity Assessment (Element) (§3.3.4).
4 The schema-validity of each attribute information items among
the [attributes] of E has been assessed as described in
Schema-Validity Assessment (Attribute) (§3.2.4).
Validation Rule: Schema-Validity Assessment (Element, Type)
The schema-validity of an element information item E has been
assessed against a type definition T if and only if:
1 The type definition T is not absent.
2 The local validity of E with respect to T has been evaluated
as described in Element Locally Valid (Type) (§3.3.4).
3 The schema-validity of each element information items among
the [children] of E has been assessed as described in
Schema-Validity Assessment (Element) (§3.3.4).
4 The schema-validity of each attribute information items among
the [attributes] of E has been assessed as described in
Schema-Validity Assessment (Attribute) (§3.2.4).
Notes
(1) It would be convenient if section 5.2 were modified to mention
that a processor may 'stipulate' a declaration or definition only for
the validation root element of a particular schema-validation episode.
(2) Note that the wording above eliminates the redundant rule 1.1.3 of
the current SVA(E). If the evaluation of Element Locally Valid
(Element) requires the evaluation of Element Locally Valid (Type),
then it necessarily requires that clause 1 of Element Locally Valid
(Type) (that the type definition not be absent) be satisfied. If that
clause is not satisfied, then Element Locally Valid (Type) cannot be
evaluated, and if that is so, then Element Locally Valid (Element)
cannot be fully evaluated either. The only effect of SVA(E) clause
1.1.3 is to single out any cvc-elt.5.1.2 or cvs-elt.5.2.1 errors which
contain cvc-type.1 errors, and wrap them in an additional
cvc-assess-elt.1.1.3 error. If this extra wrapping is important to
any WG members, I would be grateful to know more about its utility.
(3) The wording above relies on the addition, somewhere in a section
on notation, of some wording like this:
For convenience, qualified names whose namespace name is
'http://www.w3.org/2001/XMLSchema-instance' are written using
QNames with the prefix 'xsi'. In practice any prefix may be used
and processors must not treat the prefix 'xsi' specially.
and optionally also of definitions or notes like the following:
As noted elsewhere, the input to schema-validity assessment
includes a input information set. In practice, this input
information set will sometimes but not always be derived from an
XML document. For brevity, we sometimes (not always) refer to the
input information set as 'the document', and to its element
information items and attribute information items as elements and
attributes. Nothing in this specification depends upon any
distinctions between the serialized form of an XML document and
its information set, and therefore no ambiguity is introduced by
this simplification of terminology.
We say that an element E 'has' an attribute A if and only if there
is an attribute information item among the [attributes] of E whose
expanded name matches the name A.
When we speak without qualification of 'the value' of an attribute,
we mean the 'actual value' of that attribute information item.
(unless, of course, we mean the 'normalized value'. I don't have the
energy to look that up just now.)
(4) It may be better to add an escape clause for 'skip' wildcards in
rule 3 of the two new schema-validity assessment rules. Rules 2 and 3
of SVA (Element, Element Declaration) could read
2 The local validity of E with respect to D has been evaluated
as described in Element Locally Valid (Element) (&sec;3.3.4).
In the course of this local validation, each child element
of E will be assigned a 'context-determined declaration'.
3 The schema-validity of each element information items among
the [children] of E has been assessed as described in
Schema-Validity Assessment (Element) (§3.3.4), unless the
child's context-determined declaration is the keyword 'skip'.
If the child's context-determined declaration is 'skip',
the schema-validity of the child must not be assessed.
with a similar change to rules 2 and 3 of Schema-Validity Assessment
(Element, Type). In this case, clause 3 of Schema-Validity Assessment
(Element) should be deleted.
If we do this, we may have rendered our distinction between 'strict
assessment' and 'assessment' unnecessary; I have not tried to track
down all uses of the term 'strictly assessed' to find out whether this
is true or not.
(5) The non-determinism of clauses 2.1 through 2.3 of the proposed
revision (stipulated type, xsi:type, both) seems like the simplest way
to write the rules, but I am not deeply committed to non-determinism
here. It just seemed simpler than adding phrases like "and the
element information item has no xsi:type attribute" and "and the
processor has not stipulated a type definition".
4 DETAILED TRACE OF VALIDATION PROCESS
For those skeptical of my analysis, this section provides a detailed
account of what rules I believe a conforming processor must follow /
satisfy / check in validating a particular example document. This
allows those who disagree with me to identify in a fairly narrow way
the point at which they believe I have misinterpreted the spec.
Example: we have a schema and an instance, with a skip wildcard in the
schema and some stuff in that subtree which might theoretically match
top-level elements. [Only extracts of the schema are shown below; the
full schema document and the sample document are attached.]
The schema says, for example,
<xsd:element name="p" type="this:p"/>
<xsd:complexType name="p" mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="this:sandbox"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>
<xsd:element name="sandbox" type="this:sandbox"/>
<xsd:complexType name="sandbox" mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="skip"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>
A sample document (with IDs all elements to simplify discussion) is:
<my:root id="r1"
xmlns:my="http://example.com/XMLSchema/sg.skip"
xsi:schemaLocation="http://example.com/XMLSchema/sg.skip
sg.20041026.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
<my:p id="p1">This is a sample document.</my:p>
<my:p id="p2">It includes some paragraphs, and then a sandbox
element.</my:p>
<my:sandbox id="s1">The sandbox element in turn contains some
subelements:
<my:p id="p3">This is some <my:term id="t1">random XML</my:term>.
It's not actually a valid paragraph (p element)
according to our schema.</my:p>
<my:p id="p4">This one, though, is valid -- or would be, if we
validated it. Do we validate it?</my:p>
<randomXML id="r2">This is really, REALLY random.</randomXML>
</my:sandbox>
<my:p id="p5">Just for comparison, let's repeat that invalid
paragraph outside the sandbox.</my:p>
<my:p id="p6">This is some <my:term id="t2">random XML</my:term>.
It's not actually a valid paragraph (p element)
according to our schema.</my:p>
<my:p id="p7">The document concludes with another paragraph.</my:p>
</my:root>
The spec is I think mostly pretty declarative about when things have
to happen, so there is no particular order in which we have to do
things, except that context-determined declarations for children are
established during the validation of a parent, so it's natural to work
top-down or left-right, rather than bottom-up. For simplicity, I'll
assume our strategy is to check / enforce / satisfy each rule in turn,
calling other validation rules as if they were procedures and keeping
a stack of rule-satisfaction obligations. I don't think this is
surprising or controversial, but I mention it because I think the
stack isn't required by the spec; it could be a queue, or anything you
like, at least in principle.
I get tired of typing names like 'Element Locally Valid (Element)' so
I allow myself sometimes to abbreviate in what I hope are obvious ways
-- ELV(E) for the phrase just given, for example.
Validation starts (both in Xerces and xsv) by default at the root
element (r1) in lax mode, according to rule 3 of section 5.2. The
validator finds an element declaration for my:root and (following rule
3) tries to follow validation rule SVA (Element) of section 3.3.4.
SVA (Element) says if we want to validate against an element
declaration (1.1), then (1.1.1) we have to have an element
declaration. We do, by rule 1.1.1.3 (we have no context-determined
declaration, so it is not 'skip', and the QName resolution led us to
the declaration for 'root' in the target namespace). Rule 1.1.2 says
we have to evaluate the element's local validity using VR Element
Locally Valid (Element). We go there, after pushing VR SVA (Element)
for r1 and this:root on the stack.
Element Locally Valid (Element) says (1) the element declaration has
to be here, (2) it can't be abstract, (3) it's nilled only if
nillable, (4) if it has xsi:type then use it, and (5) it has to be
valid against its type. Rule 5.2.1 sends us to Element Locally Valid
(Type) for r1 and type this:root. We go there, after pushing Element
Locally Valid (Element) on the stack for r1 and this:root.
Element Locally Valid (Type) wants a non-abstract type declaration (1
and 2), and 3.2 sends us to Element Locally Valid (Complex Type) for
r1 and this:root.
Element Locally Valid (Complex Type) wants a non-abstract type (again
-- rule 1). Rule 2.4 tells us to match the children against the
content model, sending us to Element Sequence Locally Valid (Particle)
after pushing ELV (CT) on the stack for the pair (r1, this:root).
Element Sequence Locally Valid (Particle) matches the children of r1
against the content model of this:root, although I'll spare myself the
task of working through the details. The sequence
my:p my:p my:sandbox my:p my:p my:p
matches against the XSD equivalent of
((this:p | this:sandbox)*, this:div*)
and assigns elements p1, p2, p5, p6, and p7 the element this:p as
their context-determined declaration. It assigns the element
this:sandbox as the context-determined declaration for element s1.
We are now done with Element Sequence Locally Valid (Particle) for the
top-level particle of this:root. The stack now reads:
--top--
VR ELV (CT) for (r1, this:root), rule 2.4
VR ELV (T) for (r1, this:root), rule 3.2
VR ELV (Element) for (r1, this:root), rule 5.2.1
VR SVA (Element) for (r1, this:root), rule 1.1.2
--bottom--
So we return to Element Locally Valid (Complex Type). Rules 3-5 tells
us how to validate the attributes, which is uninteresting to our worry
about skip wildcards, so I'll skip it. Now we're done with this rule,
so we pop the stack.
In Element Locally Valid (Type) for (r1, this:root), we are done, so
we pop again.
In Element Locally Valid (Element) for (r1, this:root), we are now
done with rule 5.2.1. There are no identity constraints, so rule 6 is
vacuous. Rule 7 is OK, because all of the IDs in the document are
unique. Pop.
We're now back to Schema Validity Assessment (Element). We have
completed enforcing clause 1.1.2 of this rule. 1.1.3 is also
satisfied, because the type this:root is present. Rule 2 says to call
Schema Validity Assessment (Element) recursively for each element
child and for each attribute.
If we push the elements on the stack in reverse document order (so we
do the first child first not last), our stack of rule-enforcement
obligations now reads:
--top--
VR SVA (Element) for (p1, this:p)
VR SVA (Element) for (p2, this:p)
VR SVA (Element) for (s1, this:sandbox)
VR SVA (Element) for (p5, this:p)
VR SVA (Element) for (p6, this:p)
VR SVA (Element) for (p7, this:p)
VR SVA (Element) for (r1, this:root), rule 2
--bottom--
(Note: I still show SVA(E) for r1 at the bottom of the stack, because
we are in the middle of satisfying rule 2 for it. I'm not eliminating
tail recursion here: it's useful, if we suddenly wonder "Why are we
doing this?" to know what rule wanted us to check this rule.)
I'm going to ask the indulgence of the reader, and skip the validation
of elements p1 and p2, which are both clearly valid and unproblematic,
and progress straight to the validation of s1.
SVA (E) for (s1, this:sandbox) says (1) that we have to validate
against either an element declaration or a type definition. We have
an element declaration, so we take rule 1.1.
1.1.1 says we have to have an element declaration in one of the
approved ways. We have it as a context-determined declaration, so
rule 1.1.1.2 applies and 1.1.1 is satisfied.
1.1.2 says we have to assess the validity of s1 with respect to
element declaration this:sandbox using VR ELV(E). Push the stack.
Element Locally Valid (Element) for the pair (s1, this:sandbox) works
as follows:
1 The declaration is not absent. OK.
2 It's not abstract. OK.
3 The element s1 is nilled only if that's OK. It's not nilled, so
all is well.
4 If there is an xsi:type use it; there is none. OK.
5 Choose one:
5.1 does not apply (no value constraint on this:sandbox).
5.2 does apply.
5.2.1 requires us to enforce Element Locally Valid (Type) on
s1 against type this:sandbox.
Push the stack; it's now
--top--
VR ELV (Element) for (s1, this:sandbox), rule 5.2.1
VR SVA (Element) for (s1, this:sandbox), rule 1.1.2
VR SVA (Element) for (p5, this:p)
VR SVA (Element) for (p6, this:p)
VR SVA (Element) for (p7, this:p)
VR SVA (Element) for (r1, this:root), rule 2
--bottom--
ELV(T) ultimately asks us to call ELV(CT). Push ELV(T) (s1,
this:sandbox) onto the stack.
ELV(CT) for (s1, this:sandbox) works like this:
1 this:sandbox is not abstract. OK.
2 If s1 is not nilled (it's not), then (2.4) validate the children
of s1 against the content model of this:sandbox using Element
Sequence Locally Valid (Particle) for the pair ((p3, p4, r2),
type(this:sandbox)/particle()).
The stack is now
--top--
VR ESLV (P) for (s1, type(this:sandbox)/particle())
VR ELV (CT) for (s1, this:sandbox), rule 2.4
VR ELV (Type) for (s1, this:sandbox), rule 3.2
VR ELV (Element) for (s1, this:sandbox), rule 5.2.1
VR SVA (Element) for (s1, this:sandbox), rule 1.1.2
VR SVA (Element) for (p5, this:p)
VR SVA (Element) for (p6, this:p)
VR SVA (Element) for (p7, this:p)
VR SVA (Element) for (r1, this:root), rule 2
--bottom--
This time we can't skip the details of the content-model validation.
And it's easy for me to get lost, so I'll have to be rather verbose,
sorry.
VR: ESLV(P) Rule 3 fires, because the content model of this:sandbox is
a sequence.
3.1 We partition the sequence (p3, p4, r2) into three
subsequences. 3 > 0, so OK.
3.2 {max occurs} is 'unbounded', rule vacuously satisfied.
3.3 Each subsequence is valid against the model group as defined
in Element Sequence Valid. If we push the subsequences onto the
stack in reverse order, the stack is now
--top--
VR ESV for ((p3), type(this:sandbox)/sequence())
VR ESV for ((p4), type(this:sandbox)/sequence())
VR ESV for ((r2), type(this:sandbox)/sequence())
VR ESLV (P) for (s1, type(this:sandbox)/particle()), rule 3.3
VR ELV (CT) for (s1, this:sandbox), rule 2.4
VR ELV (Type) for (s1, this:sandbox), rule 3.2
VR ELV (Element) for (s1, this:sandbox), rule 5.2.1
VR SVA (Element) for (s1, this:sandbox), rule 1.1.2
VR SVA (Element) for (p5, this:p)
VR SVA (Element) for (p6, this:p)
VR SVA (Element) for (p7, this:p)
VR SVA (Element) for (r1, this:root), rule 2
--bottom--
In the validation rule Element Sequence Valid for the sequence (p3)
and the model group type(this:sandbox)/sequence(), rule 1 fires,
because the compositor is a sequence. Rule 1 asks us to validate the
element p3 against the only particle of the sequence, namely the skip
wildcard, using Element Sequence Locally Valid (Particle). We push
another item on the stack and continue.
ESLV(P) for ((p3), type(this:sandbox)/sequence()/any()
Rule 1 fires, because the particle is a wildcard. The length
of the sequence is 1, which is fine, satisfying rules 1.1 and
1.2. Rule 1.3 says element p3 must be valid against the
wildcard according to Item Valid (Wildcard). Push. The stack
is now
--top--
VR IV(W) for (p3, type(this:sandbox)/sequence()/wildcard())
VR ESLV(P) for ((p3), type(this:sandbox)/sequence()), rule 1.3
VR ESV for ((p3), type(this:sandbox)/sequence()), rule 1
VR ESV for ((p4), type(this:sandbox)/sequence())
VR ESV for ((r2), type(this:sandbox)/sequence())
VR ESLV (P) for (s1, type(this:sandbox)/particle()), rule 3.3
VR ELV (CT) for (s1, this:sandbox), rule 2.4
VR ELV (Type) for (s1, this:sandbox), rule 3.2
VR ELV (Element) for (s1, this:sandbox), rule 5.2.1
VR SVA (Element) for (s1, this:sandbox), rule 1.1.2
VR SVA (Element) for (p5, this:p)
VR SVA (Element) for (p6, this:p)
VR SVA (Element) for (p7, this:p)
VR SVA (Element) for (r1, this:root), rule 2
--bottom--
Item Valid (Wildcard) checks the namespace of the element against the
wildcard's namespace constraint, using Wildcard allows Namespace Name.
Push the stack.
VR WaNN is satisfied because the wildcard constraint has defaulted to
'any'. Pop.
We're back to IV(W). List item 3 applies and said the
context-determined declaration of p3 is 'skip'. Pop.
We're back to ESLV(P) for (p3) and the wildcard. Rule 1.3 has
been satisfied. No more to do. Pop.
We're back to ESV for (p3) and the sequence. Rule 1 has fired. No
more to do. Pop.
We do the same sequence of moves (ESLV(P), IV(W), WaNN) for p4 and r2.
Now we're back to ESLV(P) for element s1 and the content model of
this:sandbox. Rule 3.3 has finished firing. No more to do. Pop.
We're back to ELV(CT) for (s1, this:sandbox). Rule 2.4 has finished.
Rules 3-5 are uninteresting for us now. Pop.
We're back to ELV(T) for (s1, this:sandbox). Rule 3.2 has been
satisfied. No more to do. Pop.
We're back to ELV(E) for (s1, this:sandbox). Rule 5.2.1 has been
satisfied. Rule 5.2.2 is vacuously satisfied. Rules 6 and 7 are
vacuously satisfied. No more to do. Pop.
We're back to SVA(E) for (s1, this:sandbox). Rule 1.1.2 has been
satisfied. Rule 1.1.3 has been satisfied. Rule 2 asks us to validate
each child of s1 using its context-determined declaration and rule
SVA(E). The stack now contains:
--top--
VR SVA (Element) for (p3, skip)
VR SVA (Element) for (p4, skip)
VR SVA (Element) for (r2, skip)
VR SVA (Element) for (s1, this:sandbox), rule 2
VR SVA (Element) for (p5, this:p)
VR SVA (Element) for (p6, this:p)
VR SVA (Element) for (p7, this:p)
VR SVA (Element) for (r1, this:root), rule 2
--bottom--
VR SVA(E) for (p3, skip) fails, because neither clause 1.1 nor 1.2 is
satisfied. The text following says that if this occurs, we can
validate with respect to xsd:anyType "if [the] context-determined
declaration [of p3] is not skip". But it is skip.
I infer that in this schema episode we are required to assess the
validity of p3, but we cannot do so.
In private correspondence, Sandy Gao suggests the correct thing to say
would be that we 'do not need to' assess the validity of p3. I think
this is not quite right.
My formulation is based on the premise that the silent assumption
throughout the spec is that once you start schema-validation
assessment with one of the three rules in section 5.2, you are allowed
to do only what you are required or authorized to do. The only way we
are allowed to validate p3 is using SVA(E). We cannot use SVA(E) on
p3, and therefore we cannot validate p3 at all.
This suggests that the difference Sandy has said he is looking for,
between the path that leads us to validate p1 and the path which leads
us NOT to validate p3, is that in the one case we have a CDD of this:p
and in the other case a CDD of 'skip'.
On the other hand, we're now in a bind. We have stuff on the stack
that we can only get off the stack if we discharge validation rule
SVA(E) for p3, p4, and r2. But (unless I have missed something, which
is not impossible although I have now rechecked this in cold blood),
the occurrence of 'skip' as the CDD for any element in a document
seems to lead to a failure of schema-validity assessment for the
validation root.
Subsequent discussion with Henry Thompson and Sandy Gao has led me to
the conclusion that Schema-Validity Assessment (Element) should be
treating CDDs of 'skip' as a special case.
--C. M. Sperberg-McQueen
Received on Wednesday, 27 October 2004 21:30:11 UTC