RE: Personal comments on Speech Recognition Grammar Spec last call

Sorry to be a space cadet, but I want to reverse what I said a bit.

Rather than say "the type indicated in the reference rules, when present" better to say "In the case that the actual resource recovered bears an indication of a type not suitable for processing, the type indicated in the reference may be used to attempt a recovery from this error."

[more below]

At 08:47 PM 2002-03-20 , Martin Duerst wrote:
>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.
>>

AG::

In the case of a conflict between the type that the application expects from reading the referring grammar and the type that the transport asserts for the entity transported, the processor does not have to go with just one or the other.  Either one could be wrong.

If one type reflects a potential success and the other type reflects a sure failure, then the processor could take the optimistic route, interpret the recovered resource representation in accordance with that type and if the recognition process (parse, etc.) succeeds, go with it.


For SGRS we have the added complexity that applicable grammars come in two equivalent forms which are expected to have different MIME types.  Making the type indication in the reference override the actual type of the grammar sent will force errors when the type indication in the reference is ABNF and the data returned are in XML, for example.  Should this be an error?

Would it possible for the processor to make the determination as to whether XML or ABNF grammars are acceptable at this point and not the referring grammar document?

Al

>>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 16:16:25 UTC