- From: Charles Hemphill <charles@everspeech.com>
- Date: Fri, 4 Nov 2011 14:06:19 -0700
- To: <olli@pettay.fi>
- Cc: <public-xg-htmlspeech@w3.org>
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> >>> >>> >>> >> >> > > >
Received on Friday, 4 November 2011 21:06:24 UTC