RE: Personal comments on Speech Recognition Grammar Spec last call

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

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 Wednesday, 20 March 2002 11:22:41 UTC