RE: Personal comments on Speech Recognition Grammar Spec last call

Hello Al,

 From your comments at the end of your mail, I think your main point is
saying that SGRS should be allowed to restrict the types of data that it
will process when dereferences a certain URI. I have nothing against that.

If a link from a place in the grammar that says 'load subgrammar' e.g. links
to a plain text document, or to an HTML document, it is perfectly okay for
the speech grammar processor to say 'sorry, this is not a speach grammar'
and treat this as an error. This is something that is already done e.g. if
I have something like <img src='test.html'> (assuming that test.html is
identified as "Content-Type: text/html"). It is so obvious that I don't think
the TAG should be bothered with it.

[Please note that in order to help the browser to get an image and not 
something
else (in case the resource is avable in more than one form), the browser will
send out something like "Accept: image/*".]


The discussion here is not about what a processor can or can not accept
when dereferencing an URI at a specific point in the grammar, but about
how the type of the thing dereferenced is determined.

Looking at the bytes themselves very obviously does not work, as the example
of trying to have a browser display an HTML doc as plaintext easily shows.
Adding 'type' attributes to the link makes it difficult to upgrade things.
It is a hack, and the quicker we can get server behavior to get better,
the quicker we can get rid of it.

Having the document sent giving the information in the header is the
right thing to do (of course the receiving end should check whether the
data fits the format indicated).

Regards,   Martin.

At 10:14 02/03/20 -0500, Al Gilman wrote:
>[personal comment for the moment.   However,this arcitectural point is linked
>to disability concerns.
>
>See <http://www.w3.org/TR/xag>http://www.w3.org/TR/xag for the current draft
>which constructs a lot of the connection, if not the implementation in 
>"grammar
>module references."

Can you give me a specific guideline/checkpoint that you want to refer to?


>see also
>
><http://lists.w3.org/Archives/Public/uri/2000Sep/0033.html>http://lists.w3.
>org/Archives/Public/uri/2000Sep/0033.html
>
>but all that one finds at that URI is me, saying the same thing, earlier.
>I am sorry I can't point to an adequate summary of the xml-uri discussion 
>which
>would substantiate this point, but I feel it was strongly in evidence there.
>Search also on "what's at the end of a namespace"]
>
>At 04:24 AM 2002-03-20 , Martin Duerst wrote:
> >
> >>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>http://www.w3.or
>g/TR/smil20/extended-media-object.html):
> >>
> >>The
> >><<http://www.w3.org/TR/smil20/extended-media-object.html#adef-media-type>
>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>http://www.w3.org/T
>R/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>http://www.w3.org/Inter
>national/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.
> >
>
>AG::  Martin, I am sorry but I have to differ with you on point #20 above.
>
>The point is that the grammar imported by URI-reference refines the
>input-domain-model of what the current process is processing.  For references
>to schemas etc. which are documents which are used to refine the processing
>model of the ingesting process, it is necessary that the ingesting process be
>able to limit what is accepted to things which are successfully interpretable
>in terms of some general model for the "patch of model refinement" that is
>learned from the external resource.
>
>For example, a normative reference to an external patch of knowledge could 
>care
>less what syntax for the RDF model it gets so long as the appropriate 
>parser is
>available to process the text, but if the requirement is for a patch of stuff
>that can be interpreted as an encoding of the RDF model, if it can't be so
>interpreted then the deal is off and what the server gave you is garbage 
>and we
>are into an error condition.
>
>This is a point that IMHO merits attention at the TAG level and I don't 
>know if
>it isn't already on their worklist.  But it comes up over and over and the
>tranditional 'type indication is advisory' convention of the hypermedia web
>where the only action on a reference is 'navigate there' does not extend
>successfully to references to patches of rule definitions to be 
>incorporated in
>a ruleset.  Point, paragraph.
>
>In other words, the SGRS has a valid requirement to impose tighter consraints
>on the admissible values and processing of the recovered 'resource' than 
>simply
>'indicated type is advisory.'  They may not have said the alternative right,
>but your original comment _should not_ be upheld.  It refers to a rule that we
>need to un-learn in order to get the appropriate use of grammars and schemas
>flowing correctly and successfully across the web address space.  We must
>recognize that for this use we need a more typeful space with type-constrained
>references, than what we have had heretofore, to get this class of use working
>right.
>
>Al

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