Re: VoiceXML2: Examples

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