This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There appear to be conflicting statements on whether or not a schema document, prior to any transformation applied by the chameleon and/or override transformations, has to conform to the schema for schema documents and to the XML representation constraints. The fact that the transformations are schema-aware implies that the input to the transformation must be valid against the S4SD, A Note in 4.2.5 (under the Schema Representation Constraint) says: "Note: It is Dold′ and not Dold, which is required to correspond to a conforming schema. In particular, it is not an error for Dold to fail to satisfy all of the constraints governing schema documents, while it is an error if Dold′ fails to satisfy them." Section 5.1 says: "two additional conditions hold; both apply to the schema document after the conditional-inclusion pre-processing described in Conditional inclusion (
The WG agrees with points a, b, and c below, but awaits the editor's input.
I think the conflict is a consequence of inattention rather than two conscious decisions that conflict with each other. The XSLT form of the chameleon transformation was introduced in a proposal primarily aimed at bug 4767 (https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b4767.html#chameleon-xslt); there was no discussion that I can remember or that I have found concerning its schema-awareness. So it may be worth discussing the schema awareness of the transforms (both chameleon and override). The current formulation of the chameleon transform uses schema awareness to identify attributes of type QName, but I think it could in principle be rewritten to act on the specific attributes we know are typed as QNames instead, without schema awareness and thus without any requirement that the input be schema-valid. That would allow us to avoid heading back into the problem of schema-validity for schema documents, which we have not found an easy one to deal with. The current formulation of the override transform is also schema-aware, but there is clearly no problem writing a schema-agnostic version.
Created attachment 1059 [details] Proposed schema-agnostic override transformation As an alternative to modifying our rules about schema-validity of the input to pre-processing steps, we could replace the current schema-aware transformations with non-schema-aware transformations. The attached version of the override transformation is such a non-schema-aware transform; the versions of the chameleon-include transform attached to bug 14448 are also non-schema-aware. I do not have a principled objection to changing the text in the way suggested in the bug description (not legible here at the moment, but recorded in http://lists.w3.org/Archives/Public/www-xml-schema-comments/2011OctDec/0004.html). It may well be that the transforms are defined in such a way that only schema-valid input is in fact guaranteed to produce schema-valid output; that seems a possible, even plausible, consequence of the simplicity of the transformations. If I hesitate to make the change, and offer this counter-proposal instead of drafting what the WG agreed upon, it is for two reasons: (1) the constraints on the input are a sore subject for some WG members and I'd rather not reopen it if we can avoid it, and (2) although it seems possible, even plausible, to believe that only schema-valid input to the transforms can produce schema-valid output, only something resembling a proof of that proposition could really carry conviction. Such a proof would really have to go almost line by line through the schema for schema documents arguing that nothing in the chameleon or override transformations could render an invalid document valid. I haven't the time to attempt such a proof, and I don't like to ask it of anyone else either. (An ideal schema language ought to lend itself precisely to proofs of this kind, but I fear the world may not yet contain any ideal schema languages.) So I make the counter-proposal of replacing the currently specified transformations with non-schema-aware equivalents. If the WG agrees, we could close this bug by adopting these non-schema-aware transforms and leaving the prose text of the spec alone.
Created attachment 1060 [details] scaffolding for running override.xsl As a convenience to anyone seeking to test the proposed change to the override transform, I attach a scaffolding stylesheet which imports the actual override.xsl. The expected usage is explained in a comment: run the transformation with the overriding schema document (D1 in the spec) as the main input document. Optionally specify an integer parameter 'nth' to select the nth xs:override element in the main input; default value of 'nth' is 1. The output is the transformed version (D2') of the schema document pointed at by the nth override element (D2). Sample test input has already been described in an earlier comment.
At its call this morning, the XML Schema WG agreed to replace both the chameleon-include and the override transformations with non-schema-aware versions as a way of resolving the conflicts identified in the bug description. The new transforms have been integrated into the status-quo documents, so I'm marking this issue resolved. Michael, would you please check that the correct transformations have in fact been integrated into the status-quo documents and then close this issue? Thank you.