RE: Personal comments on Speech Recognition Grammar Spec last call

Hello Andrew,

I'm sorry to bother you again. Based on Al's comments, I had a look
at your mail again, and found some very basic unclarity.

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.

>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.

Do you plan some change, or do you not plan any change?

At the minimum, I would like to see an explanation of the problems
with using the type attribute on the link (a very clear example would
be that somebody has some linked speech grammar files in ABNF, and
converts them to the XML notation. All the type attributes in the
links to that grammar fragment will have to be updated, which may
be a real pain), and a commitment of the WG to (some of) the
proposals for getting things improved on the server side.

Regards,   Martin.


>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).
>
>
>Please let us know if you have further comments on these issues.
>
>Regards,
>   Andrew Hunt
>   Co-editor SRGS
>   SpeechWorks International

Received on Thursday, 21 March 2002 01:22:05 UTC