This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2822 - RQ-144 Define processor-conformance profiles (WhichPSVIPropertiesReqd)
Summary: RQ-144 Define processor-conformance profiles (WhichPSVIPropertiesReqd)
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: Other All
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-11 00:33 UTC by C. M. Sperberg-McQueen
Modified: 2007-08-21 14:19 UTC (History)
1 user (show)

See Also:


Attachments

Description C. M. Sperberg-McQueen 2006-02-11 00:33:39 UTC
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.
Comment 1 C. M. Sperberg-McQueen 2006-09-19 17:16:23 UTC
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.
Comment 2 C. M. Sperberg-McQueen 2007-08-18 17:41:17 UTC
Eighteen months have passed without response from the originator of this
issue.  I think it's time to close it.
Comment 3 Noah Mendelsohn 2007-08-21 14:19:59 UTC
> 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.