Re: inline grammar example

Conversion to a data URI is easily done server-side when generating
the HTML. Client-side is a bit tricker. We could have a JS API that
supports setting the SSML as a plain string instead of a data URI.
Having the SSML structure in the DOM isn't necessary for that.

On Fri, Nov 4, 2011 at 10:09 PM, Charles Hemphill
<charles@everspeech.com> wrote:
> Yes, the same thing for SRGS.  However, utf-8 data URIs must be one line, making them extremely difficult to edit and manage.
>
> -----Original Message-----
> From: Bjorn Bringert [mailto:bringert@google.com]
> Sent: Friday, November 04, 2011 2:22 PM
> To: Charles Hemphill
> Cc: olli@pettay.fi; public-xg-htmlspeech@w3.org
> Subject: Re: inline grammar example
>
> Data URIs for the SSML are supported, so page-specific SSML can still be inlined. Just not as part of the DOM.
>
> On Fri, Nov 4, 2011 at 9:06 PM, Charles Hemphill <charles@everspeech.com> wrote:
>> Why?   Imagine if there was no inline JavaScript or CSS.  Many of the
>> same reasons apply.  I think a strong reason is page-specific content
>> generated on a server, especially for SSML.
>>
>> Some of the advantages for inline data URIs also apply.  See
>> http://en.wikipedia.org/wiki/Data_URI_scheme for a list.
>>
>> -----Original Message-----
>> From: Olli Pettay [mailto:Olli.Pettay@helsinki.fi]
>> Sent: Friday, November 04, 2011 10:22 AM
>> To: Charles Hemphill
>> Cc: public-xg-htmlspeech@w3.org
>> Subject: Re: inline grammar example
>>
>> 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>Eri
>>>>> c
>>>>> </tag></item><item>Kasraa<tag>Kasraa</tag></item><item>Axel<tag>Axe
>>>>> l
>>>>> </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>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Bjorn Bringert
> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902
>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Received on Friday, 4 November 2011 22:29:09 UTC