[Bug 3220] Terminology: "must"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3220





------- Comment #2 from noah_mendelsohn@us.ibm.com  2007-10-16 23:00 -------
For what it's worth, my opinion is:

* Regarding schema documents: We have a definition in the specification of the
requirements for a document to be a conforming schema document.  I think the
editors draft of 2.4 is fine as it is regarding schema document conformance,
and I don't think we should say anything about "errors" there.  A document
either conforms or it doesn't.   Whether that's an error for one purpose or
another is mostly beyond the scope of this Recommendation, except for use in
building a schema (see next point).  So, regarding conformance of documents, I
would not task the editors with drafting new text.  I think what we have is
good.

* Regarding processors working on non-conforming schema documents: I think I'd
say something along the lines of:  "The rules provided herein for mapping
information from an XML document into schema components, I.e. those provided
for use in *schema-document aware* processors, apply only to conforming *schema
documents*.  Accordingly, any attempt to apply such rules or similar rules to
non-conforming documents are beyond the scope of this specification.  

"Note (this is to be included after the para above):  the above is carefully
worded to account for the fact that, although schema-document aware processors
take at least some of their input in the form of schema documents, they may
acquire additional schema information from other sources as well.  Thus,
although it would be unusual, it is not strictly prohibited for such a
processor to acquire schema components from documents that resemble but don't
quite conform to the rules for schema documents, or by applying new mapping
rules that work around such "errors". What such a processor must not do is
claim that such documents are conforming schema documents, and it must not
claim to have (successfully) used the mapping rules provided herein to create
components from them.   In practice, almost all schema-document aware
processors will treat as erroneous input documents that are not conforming
*schema documents*."

I know that's a bit clumsy, but I think it's a correct explanation of how
things work.  My hope is that the last sentence clears things up, without
unnecessarily claiming that the rules are fixed when in fact they're not.  I
think the underlying design and layering is good, and indeed one can imagine
reasons for building processors that would fix up broken documents and proceed.

In principle, I think you could say something like the following as well, but I
suspect it will be confusing to the 98% of readers to whom it is not directed
anyway, so probably I'd leave it out.   Just in case it motivates anyone to
tune it up:

* Regarding errors in born-binary components:  "As noted elsewhere, schema
processors may use a variety of means to acquire the schema components to be
used for validation.  The assessment relation requires as a precondition a
schema meeting the constraints on components set out herein.  Processors may
build in such components in their code, and/or may construct them based on
various forms of processor-specific runtime input.  Whether problems with such
input cause the processor to reflect an error, and if so what sort of error, is
beyond the scope of this recommendation."

I think I can just barely live with the workgroup's agreement at the F2F as
recorded here in comment 1, but I'm not really happy with it.  The above more
directly reflects how I think things work and how we should explain things. 
Thank you.

Noah

Received on Tuesday, 16 October 2007 23:00:58 UTC