This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The list of implementation-defined features in Appendix E.1 [1] needs to be augmented to include the implementation-defined variation described in clause 1.2 of validation rule Assertion Satisfied (in Structures sec. 3.13.4.1) [2]: by default, comments and processing instructions are excluded from the partial PSVI constructed for assertion checking (and thus from the XDM instance against which assertions are checked), but at user option processors may retain comments and processing instructions instead of excluding them. [1] http://www.w3.org/TR/xmlschema11-1/#impl-def-list [2] http://www.w3.org/TR/xmlschema11-1/#sec-cvc-assertion It would probably be a good idea to check for the terms "user option", "implementation-defined", and "implementation-dependent" to see if there are other gaps in the lists of implementation-defined and -dependent features. This is an editorial rather than a substantive issue.
A question for the WG to consider: should section 2.4 say explicitly that it is implementation-defined which category of conformance is claimed by an implementation of XSD, and in particular that it is implementation-defined - whether a processor is or is not an instance validator - whether it is a schema-validity assessor (exposes more of the PSVI than a validator) - whether it is general-purpose or special-purpose - if general-purpose, whether it is also Web-aware (In some cases the answers to these will follow automatically from saying that an implementation is a general- or special-purpose validator, or assess, or a special-purpose tool.) Or is it already inescapable that any claim to conformance to the spec must provide that information? (This arises from an attempt to back-link each item in the list of implementation-defined features to the section of the spec which states normatively that that feature is implementation-defined, in particular from item 2 on the list, which is either (a) a reference to the distinction between general-purpose processors, which can acquire schema components by reading schema documents, and special-purpose processors, which cannot; or (b) a reference to the fact that for reasons which seemed good to the majority of the WG at the time) the spec does not actually require that general-purpose processors be able to read schema documents in XML form, so that it is necessary to say not only whether a processor is a general-purpose processor but also necessary to say whether it can read XML documents as sequences of characters with angle brackets.)
MK: I'm afraid that further definition becomes circular. ...: any change here seems risky. ...: mainly in a process way. MSM: the premise for any change will be that it is purely editorial, and we should consider the risk carefully.
A two-part wording proposal intended to resolve this issue is now on the member-only site: https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b15648.html https://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b15648.html Accordingly I'm marking this issue as needsReview. Note (1) that the additions we discussed this morning, about which we worried that they might arouse some process concerns, are easily separable from the other changes, and (2) that the draft proposals have not been reviewed by the other editors, so they are not responsible for any errors.)
Resolved: ammend the proposal to collapse the three changes to 2.4 into "A claim that a processor conforms to this specification MUST specify to which processor classes defined here the processor belongs."
This problem has been fixed in the WG-internal copy of the spec.