W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2002

RE: Personal comments on Speech Recognition Grammar Spec last call

From: Martin Duerst <duerst@w3.org>
Date: Wed, 20 Mar 2002 18:24:05 +0900
Message-Id: <4.2.0.58.J.20020320180435.04098f10@localhost>
To: <andrew.hunt@speechworks.com>, <www-voice@w3.org>
Hello Andrew,

Sorry to be slow in getting back to you.

At 14:03 02/03/18 -0500, Andrew Hunt wrote:
>Martin,
>
>As of the last email there were three outstanding issues.  Here is
>a summary of status/disposition.
>
>7) Please use XLink syntax: the Voice Browser working group has
>revisited the issue and reviewed work on HLink for XHTML and
>XForms.  The working group is still of the opinion that introducing
>XLink into the set of voice specifications (VoiceXML, SSML, SRGS...)
>would be inappropriate at this time though we would not rule it out
>for future versions.

Why do you think that it would be inappropriate?
SVG, as an example, uses XLink, and I haven't heard
of any problems. HTML doesn't use it, and the main
reason is that they have links with more than one URI.
But I didn't see any such URI in the Speach Recognition Grammar Spec.


>16) Utility of Scoping: a poll of folks who write grammars
>professionally showed strong interest in maintaining the public/
>private scope distinction in the specification.  You were copied
>on much of that correspondence so I won't repeat it.  Would it
>helped if the various motivations/uses for scoping were summarized
>in the specification itself?

The spec I reviewed contained some reason, but looked very week
to me. If the stronger reason(s) that people have discussed can
replace the original text, I think than should work out well.


>20) It is a bad idea to have the media type specified
>     with the reference overwrite the media type determined from the
>     actual referenced resource
>
>After your most recent email the working group revisited the issue.
>We do plan any change to the specification.  Here is our analysis of
>the issue and the reason for remaining with the status quo.
>
>Your point that neither a resource specified by a URI, nor the bytes
>returned when resolving the URI, has a unique type, is well-taken.  This
>means for example that a server is perfectly justified to return an HTTP
>header indicating a type of, say, text/plain, when the bytes are in fact
>also a valid W3C grammar.  In such a case it's perfectly reasonable for
>the consumer of the resource to interpret those bytes (in a kind of
>casting operation) as some other type than the type indicated by the
>server, when the consumer of the resource has some "out-of-band" source
>of knowledge about the resource.  The "type" attribute provides a way
>for an application developer to provide this "out-of-band" knowledge to
>the consumer (voice browser in this case).
>
>This is useful in the common case where the VoiceXML application
>developer is also in control of the bytes that the URI resolves to, but
>may not be in control of the type information returned by the server.
>This is especially important for new types, where experience shows web
>servers are frequently not configured to return the most useful or most
>specific type information for resources that conform to the new type.
>
>There is also precedent in recent W3C recommendations for such a "type"
>attribute:  from the SMIL 2.0 Recommendation, Chapter 7
>(http://www.w3.org/TR/smil20/extended-media-object.html):
>
>The
><http://www.w3.org/TR/smil20/extended-media-object.html#adef-media-type>
>type attribute value takes precedence over other possible sources of the
>media type (for instance, the "Content-type" field in an HTTP exchange,
>or the file extension).

I'm very familiar with the problem of server setup difficulties.
There is more precedence in similar areas, such as the 'hreflang'
and 'charset' attributes on HTML <a>.
http://www.w3.org/TR/html401/struct/links.html#edef-A

As far as I know, this hasn't been implemented. It's also not very
stable, because e.g. the character encoding at the resource on the
other end could change.

I think the 'type' attribute may be a necessary fallback. But I think
the main thrust of the spec and of the W3C should really be in getting
the server side up to speed. This may include various things:

- Making sure that the MIME type is actually registered.
   It's easier to convince a webmaster to add something to a config
   file if an author can point to a full registration, rather than
   just some 'customarily used' mime type.

- Saying clearly in the spec that Web server configurations should
   be updated to send the right mime type.

- Using contacts of the WG (and the W3C overall if necessary) to
   make sure the configurations in the newest releases of the servers
   are up to date.

- Providing help on a public web page on how to set up various servers
   (see e.g. http://www.w3.org/International/O-HTTP-charset.html for
    an example; I'm glad to accept suggestions for improvement).

- Ideally, combining the latent frustration about this issue in
   various WGs and Activities to some coordinated effort.


If the WG can commit in some way to a number of the above issues,
then that would be very good.


Regards,    Martin.
Received on Wednesday, 20 March 2002 07:20:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:55 GMT