W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > November 2011

Re: inline grammar example

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Fri, 04 Nov 2011 19:21:46 +0200
Message-ID: <4EB41F2A.4050407@helsinki.fi>
To: Charles Hemphill <charles@everspeech.com>
CC: public-xg-htmlspeech@w3.org
On 11/03/2011 10:23 PM, Charles Hemphill wrote:
> Hi Ollie,
>
> Thanks for asking Hsivonen.  It will be interesting to get some feedback on
> this.
>

His answer was basically "please no", and "why would you want to
inline SRGS and SSML"





> It does add to HTML, but both SRGS and SSML are already W3C standards.  I
> think this should mostly depend on how important speech is to the Web.  It's
> been getting a lot of traction, but is it important enough yet?  SVG went
> through a painful phase with plugins.  Hopefully SRGS and SSML can avoid
> this.
>
> Best regards,
> Charles
>
> -----Original Message-----
> From: Olli Pettay [mailto:Olli.Pettay@helsinki.fi]
> Sent: Thursday, November 03, 2011 12:42 PM
> To: Charles Hemphill
> Cc: public-xg-htmlspeech@w3.org
> Subject: Re: inline grammar example
>
> On 11/03/2011 08:51 PM, Charles Hemphill wrote:
>> Hi Olli,
>>
>> Thanks for your feedback.  From what I read, namespaces can be
>> included in cases such as SVG:
> http://dev.w3.org/html5/spec/Overview.html#svg-0.
>>
>> A WG proposal covers this:
>> http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html.
>>
>> Here are non-official examples:
>> http://www.tutorialspoint.com/html5/html5_svg.htm
>>
>> HTML5 is a moving target in some respects,
> Yes, HTML(5) is changing all the time, which is why the WhatWG spec is
> "Living Standard".
>
>> so some of the above could be
>> outdated.  The first reference seems to be up to date (November 2011).
>>
>> It seems appropriate for this group to advocate SRGS and SSML namespaces.
>>
>
> HTML does have special cases for MathML and SVG, the first one perhaps
> mainly because certain browser engine has supported it for a long time, and
> the latter because it is actually being used in the web.
> Namespace attributes aren't handled, but when the parser gets<svg>, it
> knows that the element is in svg namespace.
>
> I would be a bit surprised to see WhatWG/HTML WG to accept SRGS and SSML
> elements inline in the HTML.
> But I'll ask hsivonen (the HTML parsing guy).
>
> In general I think HTML Speech API has better chances to get accepted
> outside this group if it complicates rest of the web platform as little as
> possible.
> Adding a JS API is totally ok, and probably also<reco>, but bringing in two
> new XML languages to HTML sounds quite a bit more complicated.
>
>
>
>
>
> -Olli
>
>
>
>> Best regards,
>> Charles
>>
>> -----Original Message-----
>> From: Olli Pettay [mailto:Olli.Pettay@helsinki.fi]
>> Sent: Thursday, November 03, 2011 11:00 AM
>> To: Charles Hemphill
>> Cc: public-xg-htmlspeech@w3.org
>> Subject: Re: inline grammar example
>>
>> On 11/03/2011 07:44 PM, Charles Hemphill wrote:
>>> Here is an inline grammar example.
>>>
>>> There is a high-level description of the data URI scheme at
>>> http://en.wikipedia.org/wiki/Data_URI_scheme.  The official
>>> definition is at http://tools.ietf.org/html/rfc2397.
>>>
>>> While it is possible to include inline grammars with the data URI
>>> scheme, I recommend support for the SRGS<grammar>    element as well.
>>> It's much easier to develop and maintain and it's easier to build
>>> grammars on the fly with server-side scripting.  Another option would
>>> be to have the server side write JavaScript that creates the
>>> grammars, but that's another level of indirection.  Sometimes that
>>> will be handy, but often it's unnecessary overhead.
>>>
>>> For an inline<grammar>    element, there is the possibility of text
>>> appearing in the page (like the<tts>hello world</tts>    issue), but in
>>> these cases conditional coding can be used.  That's a typical
>>> approach as standards come into play.
>>>
>>> ------------------------
>>>
>>> Consider an example where you would like to select players from your
>> roster.
>>> The names come from a database, so it makes sense to generate them on
>>> the fly.  Note that this is a very simple example and could be done
>>> in other ways. Please focus on the mechanisms rather than the
>>> particular
>> example.
>>>
>>> Example1 with standard URI:
>>> We could write the grammar to a file and then reference the grammar
>>> via
>> URI.
>>> Then we end up with file overhead and temporary files.
>>> <form>
>>>      <reco grammar="http://example.com/rosternames.xml">
>>>        <input type="text"/>
>>>      </reco>
>>> </form>
>>>
>>> Example2 with data URI scheme
>>> Note that whitespace is only allowed with base64, so we must have a
>>> really long string.
>>> <form>
>>>      <reco grammar='data:text/html;charset=utf-8,<?xml version="1.0"
>>> encoding="UTF-8"?>\r\n<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR
>>> 1.0//EN"\r\n
>>> "http://www.w3.org/TR/speech-grammar/grammar.dtd">\r\n<grammar
>>> xmlns="http://www.w3.org/2001/06/grammar"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://www.w3.org/2001/06/grammar
>>> http://www.w3.org/TR/speech-grammar/grammar.xsd" xml:lang="en-US"
>>> version="1.0" root="roster"><meta name="help-hint" content="room
>>> description"/><rule id="roster"
>>> scope="public"><example>Axel</example><example>Axel Eric and
>>> Ondrej</example><ruleref uri="#players"/><item repeat="0-1">
>>> and<ruleref uri="#players"/></item></rule><rule id="players"
>>> scope="private"><one-of><item>David<tag>David
>>> </tag></item><item>Ondrej<tag>Ondrej</tag></item><item>Eric<tag>Eric
>>> </tag></item><item>Kasraa<tag>Kasraa</tag></item><item>Axel<tag>Axel
>>> </tag></item><item>Marcus<tag>Marcus</tag></item><!-- and so on up to
>>> 18 names --></one-of></rule></grammar>'
>>>      >
>>>        <input type="text"/>
>>>      </reco>
>>> </form>
>>>
>>> Example 3 with real inline grammar:
>>> Much easier to read.  More easily supports server-side scripting to
>>> plug in names (at least for humans while developing).
>>> Note that the<reco>    element is the parent of both the<input>
>>> and<grammar>   elements.
>>> <form>
>>>      <reco>
>>>        <input type="text"/>
>>> <grammar xmlns="http://www.w3.org/2001/06/grammar"
>>>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>             xsi:schemaLocation="http://www.w3.org/2001/06/grammar
>>>
>>> http://www.w3.org/TR/speech-grammar/grammar.xsd"
>>>             xml:lang="en-US" version="1.0"
>>>             root="roster">
>>
>>
>> this doesn't work. HTML doesn't have namespaces.
>>
>>
>>>      <meta name="help-hint" content="room description"/>
>>>      <rule id="roster" scope="public">
>>>        <example>Axel</example>
>>>        <example>Axel Eric and Ondrej</example>
>>>        <ruleref uri="#players"/>
>>>        <item repeat="0-1">
>>>          and
>>>          <ruleref uri="#players"/>
>> HTML parser would not understand and would, IIRC, actually expect that
>> there was</ruleref>   somewhere. (void elements, like<input>   are
>> special cases in HTML parsing)
>>
>>
>>
>>>        </item>
>>>      </rule>
>>>      <rule id="players" scope="private">
>>>        <one-of>
>>>          <item>David<tag>David</tag></item>
>>>          <item>Ondrej<tag>Ondrej</tag></item>
>>>          <item>Eric<tag>Eric</tag></item>
>>>          <item>Kasraa<tag>Kasraa</tag></item>
>>>          <item>Axel<tag>Axel</tag></item>
>>>          <item>Marcus<tag>Marcus</tag></item>
>>>          <!-- and so on up to 18 names -->
>>>        </one-of>
>>>      </rule>
>>> </grammar>
>>>      </reco>
>>> </form>
>>>
>>>
>>>
>>
>>
>
>
>
Received on Friday, 4 November 2011 17:22:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:51 UTC