- From: Al Gilman <asgilman@iamdigex.net>
- Date: Wed, 19 Feb 2003 09:15:15 -0500
- To: Max Froumentin <mf@w3.org>
- Cc: www-voice@w3.org, www-qa@w3.org
Hi, Max. <mostly agreement/> I still think that the Voice issue is limited to "you might want to use more elliptical fragments in the examples" which is an editorial issue not requiring tracking. The examples in the spec, where they cite a schema, should cite the schemaLocation that the W3C will maintain as a matter of education and not including dilatory non-information in the examples. In stating a guideline requiring the presence but not setting the value of the xsi:schemaLocation attribute an example.com URI would be better to emphasize that the guideline does *not* fix the value of the attribute. However in a specification like this which does introduce a schema as the model for this dialect, that would be out of place. This is an EO issue and just my personal opinion on the EO issue. I do have problems with the arguments that you offer, however. Nevertheless I do believe that there are a two real community issues involved here that should be pursued in QA, TAG and W3C-wide-EO circles. <details inline/> At 04:42 AM 2003-02-19, Max Froumentin wrote: >Hi Al, > >Al Gilman <asgilman@iamdigex.net> wrote: > > > http://www.w3.org/TR/xag#cp4_2 >["Provide a machine-understandable means/mechanism to get from a >document instance to the schema."] > > > One way to clearly satisfy the urgings of this checkpoint would be that, if > > a schema is available over the Web, every instance conforming to that > schema > > *does include* a working value of xsi:schemaLocation explicitly. > >I agree that this is a commendable goal, but I think that the method >you describe to implement the guideline is very wrong. Mandatory use of >xsi:schemaLocation ties the instance to not only one schema language, >but also to one particular XML Schema. What you say is wrong could be wrong, but it is definitely not the method that I described to implement the guideline. I never said that the value of the xsi:schemaLocation attribute would be fixed by the specification. Or even a specific value required by guideline. Making the attribute mandatory to be present [as with html:img.alt] in no way makes any particular value mandatory. That is a different contstraint, FIXED vs. REQUIRED. >One could very well use a RelaxNG >schema for VoiceXML, because it does additional checks, or write their >own XML Schema for it, that would perhaps be better than the normative one, >simply because the normative schema is unfortunately broken, or missed >essential checks. See the recent discussions on xml-dev about this topic. You missed the fine points of my English grammar. I said that each instance does include *a* working value of xsi:schemaLocation explicitly. I did not say every instance contains *the* URI indicated in the specification as the value of xsi:schemaLocation. The practices that you desire do indeed conform to what XAG says and what I said in my post. >As I wrote earlier I understand that schemaLocation is only a hint, >but I find that in the case of the VoiceXML2 examples, its use makes >the examples unnecessarily verbose, and that it appears to make the >schema mandatory, although one could very well validate VoiceXML2 >files with a DTD or a Schematron, or whatever. Even if the spec >provides a normative schema, it shouldn't make it the only possible >schema for that language. This is an interesting issue. Hardly a Voice-specific issue in particular. One should cite the most restrictive schema that one is confident the document will validate to. But one should use variant schemata reluctantly, and attempt to get wrinkles into a living best-current-practices schema somewhere. Having a common *model,* or interoperation assured by known relationships between disclosed models, is the holy grail of interoperability. If people simply use a common pool of symbols with arbitrary and capricious models, interoperation takes a heavy setback. On the other hand, there has to be some flexibility in the system somewhere. How to manage that is the job our process is struggling to learn. There will be inter-operation problems that result if people use the same namespace with different models behind it, just because most people don't process the schema and any associated assertions; and yet instances tend to depend on the climate of assertions that are enforced in the context of origin. And depend on what they think are not constraints in this context. There is an extant TAG issue on profiling. If there are smart things to be said on this point we need to get them said so they affect the outcome there. In addition, maybe there is an EO BOF topic for the Plenary in "how do we foster good exposition in the W3C document product?" Note that I am an advocate at times of using and announcing you use of content models other than the one in the spec at times. http://lists.w3.org/Archives/Public/www-validator/2002Nov/0127.html In this case I would indeed recommend that webmasters check their pages against a stricter-than-spec DTD that requires the 'html:any.id' attribute to satisfy the 'name' production as in XHTML 1.0 when publishing content in HTML 4.0 (and not merely the 'cdata' production). And WAI has concerns about the clarity and readability of specifications (when reading through a screen reader, for example). But I don't think that the Voice list is where we are going to build a quorum of who it takes to make a difference. The Voice group has serious issues to deal with on their specifications. I don't think that they should be held to account for a claimed technical requirement of their specification which isn't there, but rather is based on an over-hasty reading of the examples. We simply can't get to that sort of a standard at this time. One has to worry about appearances, but at a second priority after we have what the spec *actually says* working. Let's continue to push these ideas in the network of activities. Al
Received on Wednesday, 19 February 2003 09:14:59 UTC