RE: Personal comments on Speech Recognition Grammar Spec last call

[personal comments back]

At 05:15 AM 2002-02-24 , Martin Duerst wrote: 

>>In cases where the media type conflicts with the resource (not the
>>http declared type) it is considered an error.
>
>Sorry, but this is not the way the Web is defined to work.
>First, a resource doesn't have a media type (e.g. what's the media
>type of the resource http://www.w3.org/Icons/w3c_home? It's
>available as gif, as png, and a svg, as far as I know). Second,
>the bunch of bytes returned when resolving a resource also don't
>have a media type. For example, what's the media type of the
>following file:
>
>This is my first HTML page: Hello World! 
>
>It looks quite a bit like HTML. But strictly speaking, it isn't.
>(no title).
>And what if the server wants to make sure that this is displayed
>as text/plain? So trying to rely on guessing the type of the
>bytes sent over is very much guaranteed to lead to strong
>interoperability problems.
>
>Also, I know the argument about server configuration quite well,
>but it's much more severe for 'charset' information. For a new
>media type with a new extension, it's not really that much of a
>problem.
>
>Also, the solution you currently choose would be in conflict with
>what other W3C specs have done. The most obvious example is SMIL,
>where the <audio> or <text> or <video>,... is purely advisory.
>If necessary, this may have to be looked at at a higher level than
>the WG.
>

Yes, this is an issue of very broad applicability, and calls for a general solution. 

On the other hand no, the idea that references to external resources are not allowed to constrain the type of something referenced is not OK to extrapolate forever.  Can a Web Services composition language tolerate this level of laxity?

In referring to a schema to which the current instance conforms, it would seem highly plausible that more control be exercised by the dialect of the current instance over the type of the resource representation actually employed in processing the current instance making the reference.  That is just offered as a plausibility or existence argument, not the full extent of this condition.  This came up in the discussion of URIs in namespace practice kicked off by relative URI-references on the xml-uri list.

An example in current W3C technology that clearly breaks if the type of a referenced resource is not constrained is provided by the def/ref cycle in SVG.  See for example:

 5.6 The 'use' element
 http://www.w3.org/TR/SVG/struct.html#UseElement

See also XML Inclusions, for example

 Included Items when parse="xml"
 http://www.w3.org/TR/xinclude/#xml-included-items

In this case if the representation recovered for a cited resource cannot be coerced to text/xml this should be recognized as an error.

It is not enough to leave this at "this is not how the Web is defined."  The Web needs to grow up and gain some further definition in this area.

Sorry I am not up on the TAG enought to point to the places this crops up in their current queue of recognized issues.  But I would be surprised if it isn't in there.

It is a good idea for the constraint language in the Voice specification to be reviewed by the TAG.  But it should not be considered a_priori unallowed for a reference to an external object to throw an error if the object it gets violates some sort of type constraint.

Al

Received on Monday, 25 February 2002 09:06:06 UTC