[Bug 11354] Mentions of "override" outside of the override section

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

--- Comment #5 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-03-07 18:34:21 UTC ---
Henry Thompson writes:

    Dold' ... will _always_ contain as many <override>s as the
    sum of the number of <override>s and the number of <include>s 
    it started out with.

Yes.  The misconception that afflicted us on 4 February 2011 was
a result of confusing the proposition that "the semantics of override
reduce to the semantics of include" (true) with the proposition "the
transformation works by eliminating occurrences of override" (false).

HT also asks

    When we introduced the explicit transform mechanism to handle 
    both chameleon include and override, why did we add the "not D2 
    but D2'" and "not Dold but Dold'" Notes (and of course the
    normative bits which justify them)?  In what circumstances would D2 be
    non-conforming but D2' be conforming?  Likewise for Dold and Dold'?

Chameleon processing appears to have been changed in response to 
bug 2067, which was closed in February 2007 in New
Orleans, then closed again in July and August 2007 (having apparently 
been reopened after the New Orleans meeting), and re-opened and closed
a third time in May 2008.  

The override facility was first adopted as a resolution of bug 4767 and
then modified in connection with bug 6021.

That may help narrow searches through the decision record.

The wording proposals adopted at various times (and some other
proposals considered but not adopted) are pointed to from the editorial
pointers page at

  http://www.w3.org/XML/Group/2004/06/xsd-ed-pointers.html
  (member-only link)

Without reviewing the relevant parts of the decision record, I'll observe
that in each case, the transformation gives us two schema documents to
deal with, and so we must specify whether the constraints in the spec
apply to the transformation's input, to its output, or to both.  

In the case of override, it seems clear that errors in the transformation
output need to be detected and errors in the input need to be detected
only if they lead to errors in the output.  There might be a validity error 
in a declaration (perhaps both @ref and @name are specified on an 
element declaration), a conformance error (perhaps minExclusive is 
applied to a string type), or possibly other problems (can't think of 
any but don't want to bother trying to prove they couldn't exist) in a 
declaration overridden by a corrected declaration in the overriding 
document.   Since the overridden source declaration is overridden, 
it isn't used to try to create or identify any components, so its errors 
do not need to stand in the way of identifying the schema to be used
in validating the document.  

In the case of chameleon include, I am not sure off hand whether there 
is any logical relation between the validity or conformance of the input 
schema document and those of the output document; it may well be 
that if one is valid and conforming, we know that the other is, as well.  
If so, it suffices to check just the one.  If they are not logically tied
together, then it seems clear that it is the validity and conformance 
of the result of the transformation that we should be concerned with,
while those of the input document are at most of academic interest.

In some cases, of course, errors arise not from a schema document in
isolation but only when schema documents are combined.  If we have

  - schema document A declares element E (unqualified) as xsd:date
  - schema document B in namespace N declares element N:E2
    and performs chameleon inclusion of schema document C
  - schema document C declares element E (unqualified) as xsd:int

then the combination of A and untransformed C will not be a 
conforming schema (two conflicting declarations for element {}:E),
while the combination of A with chameleon(C,N) will be fine.

I conclude that there is no need for the input to the transformations to
be conforming schema documents, only for the output to be.

In this, transformations defined on schema documents differ from
transformations defined on schemas.  For a transformation defined
on a schema rather than on a schema document, the conformance of
the starting schema document is of critical importance, and there is
no second schema document to be concerned with, only a second
schema.  There is, in the nature of the case, no way to avoid having to
check two schemas for conformance to the spec: the input schema
must be checked as a pre-condition for the transformation, and the
output needs to be checked again, since in the general case there
is no guarantee that the transformations on schemas defined by XSD
preserve conformance either of individual components or of the
schema.

-- 
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 Monday, 7 March 2011 18:34:23 UTC