- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 07 Dec 2007 18:33:02 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5297 ------- Comment #4 from cmsmcq@w3.org 2007-12-07 18:33 ------- Comments #1, #2, and #3 all argue that we should not make any change here, first because there is no need to support every conceivable use case and second because there are good reasons for validation to be context independent. These arguments are not wholly satisfying. The first presents a generally accepted principle as if it were an argument: we cannot support all conceivable use cases. This is not in dispute, in part because some of us are well aware that it is not possible to do so even in theory -- but it does not address the salient question, which is: should we seek to support *this* use case? This particular example is not a discovery made after long search: the context awareness of HTML form and input elements has been a topic of conversation, in the context of schema languages and their expressive power, for about as long as HTML has had DTDs. The last I heard, HTML was not an obscure language of no particular interest for the world at large; the ability to specify features built into widely used markup languages is, I think, something the designer of any mechanism for specifying markup vocabularies should be thinking hard about, if the mechanism being designed is intended to be of general use. The case for taking this use case seriously is simple: HTML is the flagship markup language of W3C, and the feature makes it possible to define a well known part of HTML precisely and concisely. Our earlier decision not to support it was based on a false premise. The case against considering this use case seriously appears to be: the W3C's schema language doesn't really have any need to support the features needed to define W3C's markup languages, or any other obscure and little-used languages. These arguments are most charitably described as laughable; perhaps there are others. The second argument offered is that there are good reasons for validation to be context-free. If those reasons exist, deciding on this issue will involve weighing them carefully against the reasons for making it possible to write an XSDL schema that expresses an important constraint in (X)HTML. Such a careful weighing of one point against another will be easier if the reasons for context-free validation are identified. Comment #3 does not identify any arguments, architectural or otherwise; it only says they exist. Michael Kay does identify a specific reason: bottom-up construction. I think he is correct that the locality of validity may make it easier to guarantee the validity of larger constructs made from smaller ones, and I expect that it will be useful to distinguish different kinds of validity which depend on different parts of the document, just as we do now in distinguishing local validity from 'deep' validity. It's not entirely clear to me how to weigh against each other the two situations (A) Validity is simple to calculate but does not include some simple mechanically checkable constraints imposed by the definition of the vocabulary. So "validity" is less useful as a concept than it might be. (B) "Validity" included more of the constraints imposed by the definition of the vocabulary, so it's a more useful concept than in (A). But it's more complex to calculate. But it does seem clear to me that dismissing the requirements of HTML out of hand, as if they were a corner case, is not the right way to weigh them. And assertions that there are good architectural reasons for something do not carry, in a careful Working Group, the same weight as the architectural reasons themselves.
Received on Friday, 7 December 2007 18:43:48 UTC