This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This issue was originally reported by Noah Mendelsohn. [N.B. this candidate requirement was originally posed in the terms given by the email from Noah Mendelsohn cited below; it was amended on 25 March 2004 to read as follows:] "[Definition:] Minimally conforming processors must completely and correctly implement the Schema Component Constraints, Validation Rules, and Schema Information Set Contributions contained in this specification." This appears to require that conforming processors report the PSVI. This would rule out, for example, processors that implement a simple validation check function such as: boolean IsValid(schema, instance) But such a function is clearly useful in query languages, spreadsheets, and other systems that manage or access instance documents. Other interesting if somewhat less common reports might be to give only the type assignments of each element or attribute, etc. Even for validity, some applications will want details of validity down the entire tree, while others will want only the net result at the root. Interestingly, many applications will want the "value" from a simple type value space, which for some reason we have declined to include. The range of useful processor APIs goes well beyond providing the full PSVI and only that. We should modify the spec in the light of that fact. * There should be a clean separation between descriptions of the language(s) and descriptions of processors. * We should make a good attempt to call out (in a separate chapter) a particular specification of processor classes that we hope will be useful and widely deployed. * We should make clear that other processor class descriptions are OK; they are not to be thought of as second-class compared to ours. See mail: from Noah Mendelsohn (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Oct/0106.html) In January 2005 it was agreed to change the title of this requirement from *Which PSVI properties must processors report?* to *Defined processor conformance profiles* or something similar. This item was discussed in the meeting of 2004-03-11 (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Mar/0026.html). This item was discussed and amended in the meeting of 2004-03-25 (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Mar/0133.html). The amended requirement was classified as Req. This item was discussed in the meeting of 2004-04-01 (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Apr/0003.html). We identified two points (originally formulated as part of RQ-142 but moved here by WG decision): Any specification of a class of processors (including ours) can require specific additional information not in the PSVI, though should note that interoperability is better if applications depend only on the properties present in the PSVI as we define it. In our own specification of processor classes, we should be explicit that processors may provide additional information. (Or alternatively be explicit that they must not -- but the chair believes the WG consensus was to allow it.) Wording to resolve this issue has been drafted and was discussed by the Working Group at the Technical Plenary in 2005; the proposal is to be revised by the editors in light of that discusion.
The wording proposal of early 2005 was revised and reviewed by the working group during the summer of 2006; a series of amended wording proposal was considered and adopted by the working group over the course of August, and the result is incorporated into the working draft published 31 August 2006. The changes are pervasive, but the processor-conformance profiles most clearly envisaged when this issue was raised are in appendix D.1 (http://www.w3.org/TR/xmlschema11-1/#var_psvi). While that appendix will need to be maintained as further revisions are made to the spec, I believe the issue originally raised has been resolved and am accordingly marking this item so, and adding Noah Mendelsohn, as the originator of record, to the CC list. Noah, please confirm that you are happy with the WG's resolution of this issue by changing the status of the issue from Resolved to Closed, optionally with a comment. If you are not happy, please change the status from Resolved to Reopened, and use the comment field to explain why. If we don't hear from you one way or the other within two weeks, we will assume you are happy with the resolution.
Eighteen months have passed without response from the originator of this issue. I think it's time to close it.
> Noah, please confirm that you are happy with the > WG's resolution of this issue by changing the > status of the issue from Resolved to Closed, > optionally with a comment. If you are not happy, > please change the status from Resolved to > Reopened, and use the comment field to explain > why. If we don't hear from you one way or the > other within two weeks, we will assume you are > happy with the resolution. > [...] > Eighteen months have passed without response from > the originator of this issue. I think it's time > to close it. I'm very sorry. As you might have guessed, I managed to miss the fact that we were formally waiting on a response from me. For the record: yes, I find that our resolution is satisfactory for Schema 1.1. Maybe or maybe not experience with Schema 1.1 will suggest additional things we should do later, but I concur that we are doing the correct thing in closing this issue at this time. Thank you, and please accept my apologies for being so tardy. Noah Eighteen months have passed without response from the originator of this issue. I think it's time to close it.