- From: Bjorn Bringert <bringert@google.com>
- Date: Fri, 4 Nov 2011 21:22:00 +0000
- To: Charles Hemphill <charles@everspeech.com>
- Cc: olli@pettay.fi, public-xg-htmlspeech@w3.org
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>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> >>>> >>>> >>>> >>> >>> >> >> >> > > > -- 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 21:22:35 UTC