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 7695 - Conformance
Summary: Conformance
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: David Ezell
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2009-09-22 07:44 UTC by Michael Kay
Modified: 2010-11-10 17:50 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2009-09-22 07:44:47 UTC
The CR document says in its Conformance Section (2.4): "The Working Group expects to revise this discussion of conformance in future."

In order to exit from CR we need (a) to demonstrate that we have tests aligned to the features that are mandated for conformance, and (b) that there are products that implement these features.

At present (a) it is possible for a non-conformant implementation to pass all our tests (because we do not test the construction of a PSVI) and (b) it is possible for a conformant implementation to pass no tests (because our tests require that the processor be "schema document aware").

Furthermore, experience with XSD 1.0 suggests that products that perform validation without generating a PSVI have proved successful and interoperable in the market, and it is therefore shooting ourselves in the foot not to recognize such products as being at some level conformant with our specification.

I propose that we identify three basic units of conformance:

(a) A .schema document processor. constructs a schema from a set of schema documents. Such processors must, when processing schema documents, completely and correctly implement (or enforce) all ·Schema Representation Constraints· in this specification, and must adhere exactly to the specifications in Schema Component Details (§3)  for mapping the contents of such documents to ·schema components· for use in ·validation· and ·assessment·.

(b) An .instance validator. determines the schema-validity of an instance, specifically, it is able to determine whether an element information item satisfies the constraints embodied in an XSD schema;

(c) An .instance assessor. synthesizes the overall validation outcome for an instance. Specifically, it is able to process an element information item by combining local schema-validity with the results of schema-validity assessments of its descendants, if any, and adding appropriate augmentations to the infoset to record this outcome.

Products may claim conformance with any or all of these three units. The published test suite may be used to substantiate a conformance claim for a product that claims conformance with (a) and (b).
Comment 1 Noah Mendelsohn 2009-10-07 20:31:06 UTC
In doing a bit of looking at this issue, I was struck by what may or may not be better tracked as a separate concern.  

Specifically is the intended distinction (if any) between minimally conforming processors (a term formally defined in section 2.4), and "conforming" as used in the preamble to Appendix C.1, a clear one?  

FWIW:  my recollection is that in XSD 1.0, we introduced the term "minimally conforming" to distinguish those implementations that are schema processors at all from those that are not.  All our other conformance levels were described as being minimally conforming + having some other features.  So, if your processor wasn't at least minimally conforming, our spec didn't provide conformance req'ts for you.

Section C.1 now has statements like:

"...the information set taken as input is augmented in the course of schema-validity assessment. Conforming processors may provide access to some or all of this information..."

Note also that in 2.4 we say:  

"[Definition:]  Minimally conforming processors must  completely and correctly implement the ·Schema Component Constraints·, ·Validation Rules·, and ·Schema Information Set Contributions· contained in this specification."

That is a bit ambiguous, but at least suggests that the whole PSVI be exposed by a minimally conforming processor.  Taking the two quotes together, I think one concludes that either (1) there are processors that are conforming but not minimally conforming, which seems strange to me or (2) the presentations in 2.4 and C.1 were never reconciled.

I think that cleaning this up is relatively easy, and doing so is likely to give us a slightly cleaner backdrop against which to consider MK's concerns.  I think I could live with either of the following resolutions, both of which collapse the two terms into one.  Either:

A)  In section 2.4  change the text to read 

"Minimally conforming processors must  completely and correctly implement the ·Schema Component Constraints·, ·Validation Rules·, and, >optionally, some or all of the< ·Schema Information Set Contributions· contained in this specification.""

Change section C.1 to read:

"...the information set taken as input is augmented in the course of schema-validity assessment. >Minimally conforming< processors >MAY< provide access to some or all of this information..."

    -- or --

B)  Get rid of the term minimally conforming completely.  In its place, make "conforming processors" a termdef" in section 2.4, and change the text to read 

">All< ·conforming processors· must  completely and correctly implement the ·Schema Component Constraints·, and ·Validation Rules·.  >Additionally, conforming processors MAY report some or all of the< ·Schema Information Set Contributions· contained in this specification. >(See Appendix C.1)<""

No changes to C.1.

Optionally:  add a note indicating that the term "minimally conforming" has been retired, but that where an equivalent is needed, readers should look to the XSD 1.1 conformance constraints placed on "all conforming processors"



I have no strong reference between (A) and (B), and I'm open to other simple resolutions, but I do think this is worth cleaning up.

The above suggestions are not meant to directly address MK's concerns, with which I have at least some sympathy, but rather to suggest cleanup that's worth doing in any case.  I think we'll have an easier time considering Mike's request if the underlying exposition is a bit cleaner.

Thank you.

Noah

P.S. I couldn't quite decide if this was better reported as a separate bug.  Feel free to move it if you prefer, to ask me to resubmit.
Comment 2 Michael Kay 2009-10-07 20:44:24 UTC
Thanks for this extra input. I had completely overlooked the existence of the named PSVI subsets defined in C.1. They do indeed shed a new light on the intent of the WG with regards to the conformance status of a processor that does not make the full PSVI available to the application (and provide extra justification for the need to revise section 2.4 to achieve consistency).
Comment 3 Noah Mendelsohn 2009-10-07 23:21:59 UTC
Yes.  The fact that someone as well informed as you would not immediately find his way from section 2.4 PSVI references to Appendix C suggests that at least some clarification is needed.  Indeed, I had assumed you were well aware of Appendix C and did not find it helpful in addressing your concern.

FWIW, I think where we stand is:

* Appendix C makes clear that conforming processors need not expose the whole PSVI

* Appendix C provides a >vocabulary< to be used when documenting particular levels of conformance, but it does not in any other sense define conformance for processors as a whole

* I infer that you would be happier if we documented a named conformance level for processors (call it instance validating for now) that required processing of sets of schema documents, performed validation on on input infoset, and provided as output the Root-Validity subset of the PSVI.

Do I have that right?  I would like to hear from editors like MSM whether there are problems doing that, and if not, how they would propose to do that, but I have some sympathy with the suggestion.  

Also, since some of the other PSVI levels like Type-Aware Subset are defined as supersets of the Root-Validity Subset, then I presume that any processor that supported (e.g.) Type-Aware, and met the non-PSVI requirements, would also be a conforming "instance validator".  

So, if Saxon reported just Root-Validity, and Xerces reported Type-Aware, both might be conforming "instance validators".  Do I have that right?

Thanks.

Noah
Comment 4 David Ezell 2009-10-16 16:01:06 UTC
Agreed on 2009-10-16 at the telcon.
Comment 5 C. M. Sperberg-McQueen 2009-11-06 16:17:44 UTC
A wording proposal for this issue is on the server at 

  http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b7695.html
  (member-only link)
Comment 6 C. M. Sperberg-McQueen 2009-11-06 22:11:26 UTC
The wording proposal mentioned in commet 5 was adopted with amendments and clarifications (including the required design decisions) on today's XML Schema working group call.  The salient amendments were:

  1 The term 'annotator' was replaced by the term 'schema-validity assessor' (or just 'assessor' for short).
  2 Assessors are defined as processors which provide access to the entire PSVI, on the grounds that specifying that they expose some arbitrary subset would make the conformance class meaningless.  Note that processors which expose arbitrary subsets remain conformant to the spec; the question was not about conformance but about which conformance class they fall into.
  3 The material after the definition of 'general-purpose' ("Such processors must, when processing schema documents, implement (or enforce) all ·Schema Representation Constraints· in this specification, and must adhere exactly to the specifications in Schema Component Details (§3) for mapping the contents of such documents to ·schema components· for use in ·validation· and ·assessment·.") was deleted.
  4 The inline text for validator was approved; the proposal to allow validators to use definitions of validity other than those in 2.5 (root-validity, deep validity, complete validity) was rejected, on the grounds that it would render the conformance class meaningless.
  5 The note following the definition of 'validator' was dropped.

Michael, I will leave it to you as the originator of the issue to close the issue to indicate that you are satisfied with this resolution, or to reopen it otherwise.  If we don't hear otherwise from you in the next two weeks we will assume that you are satisfied.
Comment 7 David Ezell 2010-11-10 17:50:35 UTC
The WG reported this bug as FIXED on or before 2009-11-06.  We are closing this bug as requiring no futher work.  If there are issues remaining, you can reopen
this bug and enter a comment to indicate the problem.  Thanks very much for the
feedback.