- From: <bugzilla@wiggum.w3.org>
- Date: Sat, 14 Oct 2006 13:36:32 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3817 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 elaborate? 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 orthogonality. (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