W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2006

[Bug 3817] Processor profiles for following/not following schemaLocation

From: <bugzilla@wiggum.w3.org>
Date: Sat, 14 Oct 2006 13:36:32 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1GYjgm-0000S6-1D@wiggum.w3.org>


cmsmcq@w3.org changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED
           Keywords|                            |unclassified

------- Comment #1 from cmsmcq@w3.org  2006-10-14 13:36 -------
This information (unconditionally or conditionally follow, or
unconditionally ignore, schemaLocation hints) looks at first
glance as if it were mostly covered by the current appendix D.2
(both in the most recent public working draft, and in the status
quo documents).  The list of possible component sources in D.2.1
includes schemaLocation hints, and the introductory prose in D.2
says "General-purpose processors SHOULD ... provide user control
over which methods are used and how to fall back in case of
failure."  That covers the distinction drawn in the sample text
in the description, does it not?

But since the originator of the comment is clearly familiar with
appendix D, I assume the comment is asking for something that is
not in fact already there.  I don't know what, though.  Could you

D.2 does not provide terminology for "how to fall back in case of
failure"; is the proposal in essence that appendix D should
define standard terminology to distinguish fatal errors,
non-fatal errors, warnings, or silence on the part of processors?

I wonder: is something like that really needed?  The topic
worries me; I fear that discussion on that topic would prove to
be a tar-pit; members of the WG and readers of WG minutes will
recall that even the distinctions made in 5.2 between strict
wildcard validation and lax wildcard validation struck some WG
members as saying too much about the context within which
validators operate.  Trying to provide standard terminology for
behavior when a URI does or doesn't resolve, or resolves to
something unexpected, seems like a very high-cost, and relatively
low-benefit, errand.  If serious readers believe that D.2 as
currently drafted requires either that references always succeed
or that failures of reference never be errors, then it might be
worth adding a sentence or two to dispel that confusion.

If on the other hand the proposal is that we should provide such
terminology, but ONLY for use in describing behavior vis-a-vis
schemaLocation hints, and not for use when other locations are
consulted, then I don't understand the motive for the lack of

(In reviewing the relevant text just now, I note two points that
need correction: in the intro to D, for "and to provide user
control" read "and provide user control".  And in the list of
component sources, either edit the entry for schemaLocation hints
to cover schemaLocation hints in schema documents [hints in the
case of import, at least], or add a separate entry for them.)
Received on Saturday, 14 October 2006 13:36:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:05 UTC