[Bug 10664] Inconsistency in Appendix G (summary of changes)

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

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needsDrafting               |needsReview

--- Comment #1 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-01-07 04:04:01 UTC ---
There is perhaps always some risk in a summary of changes.  It serves as a
summary only if it's kept short and brisk, but if the descriptions are too
short they risk being misleading or producing an apparent or real contradiction
by passing over in silence (as here) some of the details of the changes.  If,
on the other hand, the list of changes covers every change in all its gory
detail, it is likely to be as hard to read as the main body of the spec.  

In this case, I suppose Michael is right to suggest the text has shied too
vigorously away from the Charybdis of excessive detail, and has steered
straight into the arms of the Scylla of inadequate explanation.

On the self-serving theory that I won't be the only member of the WG who must
ask "what changes, exactly, gave rise to items 1 and 4 in section G.1.12, and
why do they appear to contradict each other?" I'm going to record here my study
of the change records and a summary of the changes I think each item is trying
to describe.

Item 1 is marked with diff group vm3-1, which is one set of changes made in
connection with 'versioning mechanism 3'.  It was adopted, together with a host
of other changes, in the face to face meeting of Oct/Nov 2006 in San Jose,
California.  The document "XML Schema Working Group Framework for discussion of
versioning" at http://www.w3.org/XML/2004/02/xsdv.html describes V-M3 this way: 

    3.3. V-M3 Fallback from xsi:type value to declared element type

    if an xsi:type in the instance names an unavailable type, allow the 
    schema-validity assessor to use the declared type of the element instead. 
    If the element is valid against a type legally derived from the declared
type, 
    then either the entire element instance will be valid against the declared 
    type or a proper prefix of it will be valid; make it convenient to tell 
    from the PSVI what prefix of the instance is valid (if any). 

The changes marked as part of diff group vm3-1 (and related diff groups)
include these:

- In 3.3.4.3 add Note about what happens when xsi:type fails to resolve or
resolves to an unsuitable type definition (one that fails to override the
declared type), and where to find the information in the PSVI.  (I.e.:  the
declared or selected type is used, and [local type validity] says whether the
element is locally valid against the governing type.

- In 3.3.5.2, add a new infoset contribution, [subsequence-valid], which is
true iff an element is locally invalid because attributes or elements are
present which don't match the content model or attribute declarations of the
element declaration, but would have satisfied clause 1 of Element Locally Valid
(Complex Type) if those children and attributes had not been present, and
otherwise false.

- In 3.3.5.3, add infoset items [expected element declaration], [declared
type], and [local element validity].

- In 3.3.5.4, add infoset items [type fallback], [local type validity], and
[descendant validity].

The property [type fallback] has values which indicate how the governing type
was selected when an xsi:type in the instance fails to resolve successfully: 
'declared' if the declared type of the element is used; 'selected' if the
governing element declaration has a type table and the selected type is used as
a fallback when xsi:type fails to resolve; 'lax' if xs:anyType is used as the
fallback type.  

The property [local type validity] indicates whether the element is locally
valid against its governing type definition.

The property [descendant validity] indicates whether the descendants and
attributes of the element are all valid or not.   (Together with [local type
validity]. this allows consumers of the PSVI to figure out, for a given invalid
element, whether the problem causing invalidity is at the top level or among
the descendants, or both.)

- Added 3.4.5.2 defining infoset contribution for 'match information', which
allows consumers of the PSVI to know (among other things) whether elements in
the input match element particles or wildcard particles in the relevant content
model.  

So much for the summary of changes.  Item 1 in G.1.12 is clearly misleading in
referring to lax validation; in fact in the cases that motivated the change,
the fallback is most often going to be to the element's declared type.

Item 4 of G.1.12 is marked as referring to diff group b4299, which resolved bug
4299 and was adopted 9 March 2007, with an additional change approved 23 March
2007.  The changes made by this cluster of diff groups include:

- In 3.2.4.1 add a clause to Attribute Locally Valid saying that if the
attribute in question is an instance of xsi:type, then its value must resolve
to a type definition.  (It was clear, before, that if xsi:type did not resolve
to a type definition, something was wrong, but it was not explicitly part of
local validity of the attribute.)

- In 3.3.4.4 add clause 4 to Element Locally Valid (Type), saying that an
element E without a governing element declaration is locally valid against a
type T only if any xsi:type attribute on E resolves to T.  

(Coming back to this cold, this seems a bizarre distortion of the idea of
validity against a type; it suggests that an element with an xsi:type attribute
can never be valid against any type other than the one specified, which makes a
hash of all the usual claims and assumptions about elements valid against a
restriction always being valid against the base type.  This is a botch which
should be fixed, even if the formal semantics of QT turn out not to be
destroyed by it.  Another legacy of our failure as a WG to develop an
adequately clear conceptual framework, and of the spec's determination to make
all definitions as procedural as can be managed using language which on the
surface is declarative.)

- In 3.3.4.6, add clause 5 to the definition of governing type definition,
specifying that skipped elements have no governing type definitions.  (The
relevance of this to bug 4299 is more easily appreciated if you re-read 4299.)

I agree that the "must be" in item 4 should be recast; I think the "must"
probably should be as well.  Instances of xsi:type occur in document instances;
document instances can conform to (be valid against) a schema, but we do not
define conformance to the XSD spec for document instances, so 'must' is
misplaced here.

OK, so much for the changes in the spec that items 1 and 4 were trying to
describe briefly without getting mired in detail.

MK writes "It's hard to see how both can be true", but in fact I think both are
true, and I don't see what's hard to understand here.  The changes described by
item 4 mean that if an xsi:type attribute fails to resolve to a type definition
in the schema, then that xsi:type attribute is locally invalid.  The changes
described by item 1 specify what type definition governs the element in that
case, so that validation can proceed.  

It's true that users and implementors interested only in a boolean top-level
result, instead of in the annotated document defined by the XSD spec as the
output of assessment, will not see much difference here:  since the xsi:type
attribute is invalid, its ancestors will be invalid (unless one of them was
laxly assessed instead of being strictly assessed), and the root will be
invalid.

Tentatively, I'd propose the following rewordings:

1.  When an xsi:type attribute appears on an element and has a QName as its
value, but the QName does not resolve to a known type definition, the element
is assigned a 'fallback' governing type for validation; this will be the
selected type or the declared type of the element, if available, and
xsd:anyType otherwise.  The validation process is now explicitly defined as
including the validation of the element and its descendants; processors no
longer have the implicit option of skipping the element and its descendants.

4.  The text now specifies that if an element has an xsi:type attribute which
does not resolve to a type definition, then the xsi:type attribute is invalid;
it also specifies that if an element has an xsi:type attribute, it is not valid
against any type other than the one indicated by the xsi:type attribute.

N.B. the material following the semicolon will need to be removed or changed if
the WG agrees to my proposal that we revoke that change and impose any
necessary constraint in some more principled way. 

Since this comment includes proposed text, I'm marking it needsReview, but it
should be noted that the other editors have not reviewed or agreed with the
proposed text; they should not be held responsible for it.

-- 
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 Friday, 7 January 2011 04:04:03 UTC