Re: [XHR] chunked requests
On Thu, Dec 8, 2011 at 2:36 PM, Charles Pritchard ch...@jumis.com wrote: On Dec 8, 2011, at 1:04 PM, Wenbo Zhu wen...@google.com wrote: On Wed, Dec 7, 2011 at 6:04 PM, Charles Pritchard ch...@jumis.com ch...@jumis.com wrote: ** I think the Web Sockets spec is intended for client to server sessions like this. WebSocket protocol isn't yet well-supported by proxies. Besides, all we need here is a throwaway RPC-like request/response, and it's a bit heavy duty to use WebSocket for this use case. Isn't a chunked stream the anti-thesis of RPC? Streaming request or response does not imply bi-directional messaging, i.e. the (non-RPC) semantics of WebSocket. It looks like you're acknowledging WebSockets works while asking about what to do with current web infrastructure. It seems to me that current infrastructure is -mostly- Flash based and assumes a level of control over input: one can't send arbitrary information as a developer.. It has to be directly from a webcam or similar media stream. Do you have specific examples of existing infrastructure you're hoping to support? See below. As for the peer-to-peer communication, I imagine the WebRTC group is where you'll see more activity on this issue. WebRTC is mostly peer-to-peer UDP (e.g. RTP), and the client-to-client communication has nothing to do with either HTTP or WebSocket. And MediaStream/Stream, which has to so with your request. Not sure about the status of this spec. My original email merely tries to show the need to process/post data locally ... http://developers.whatwg.org/video-conferencing-and-peer-to-peer-communication.html#video-conferencing-and-peer-to-peer-communication I don't know that arbitrary binary data is on their agenda -- I hope it is -- for p2p communication. On 12/7/11 5:59 PM, Wenbo Zhu wrote: One use case that we have which is not currently handled by XMLHttpRequest is incrementally sending data that takes a long time to generate _from the client to the server_. For example, if we were to record data from a microphone, we couldn't upload it in real time to the server with the current API. The MediaStreaming spec also mentioned several use cases which would require streaming request data via an API: - Sending the locally-produced streams to remote peers and receiving streams from remote peers. - Sending arbitrary data to remote peers. http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html - Wenbo
Re: [XHR] responseType json
On Sun, 11 Dec 2011 15:44:58 +0100, Jarred Nicholls jar...@sencha.com wrote: I understand that's how you spec'ed it, but it's not how it's implemented in IE nor WebKit for legacy purposes - which is what I meant in the above statement. What do you mean legacy purposes? responseType is a new feature. And we added it in this way in part because of feedback from the WebKit community that did not want to keep the raw data around. In the thread where we discussed adding it the person working on it for WebKit did seem to plan on implementing it per the specification: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/thread.html#msg799 In WebKit and IE =9, a responseType of , text, or document means access to both responseXML and responseText. I don't know what IE10's behavior is yet. IE8 could not have supported this feature and for IE9 I could not find any documentation. Are you sure they implemented it? Given that Gecko does the right thing and Opera will too (next major release I believe) I do not really see any reason to change the specification. -- Anne van Kesteren http://annevankesteren.nl/
Proposed Specification for find/findAll/matches
Hi, I have reviewed all of the recent discussion and spent some time analysing JQuery, and I have compiled this rough specification detailing how I think find, findAll and matches can work. The following details the rationale for each of the design decisions made. The new methods should be available on documents, document fragments and elements, just like querySelector. The easiest approach is to put these on the same NodeSelector interface as the existing methods. This email is long and detailed. For those of you who just want the conclusion, skip to the the proposed IDL and summary. --- *Table of Contents*: 1. Methods and Return Types 2. Document Methods 3. Document Fragment Methods 4. Element Methods 5. Match Testing 6. Proposed IDL 7. Summary of Proposed Spec Changes 8. Proposed Rules for Prepending :scope --- 1. *Methods and Return Types* Throughout the discussion, there seems to be the assumption that we should have both find() and findAll() methods, which return a single matching element and a collection of all matches, respectively. One issue to decide is, based on experience with and usage of querySelector() and querySelectorAll(), whether it worth introducing the same distinction for new methods, or would it be better to just go with a single method that returns a collection? That is, is it really useful or better in practice to have the method that only returns the first match? For the purposes of the rest of this email, however, I'll stick with the assumption that we'll introduce both find() and findAll(). There is also the open issue of what type of collection should be returned by findAll(), whether it be an Array or special kind of NodeList with an Array-like interface. I have not addressed this issue in this proposal. --- 2. *Document Methods* The document.findAll() method is supposed to be designed to more closely align with the behaviour of JQuery's global $() method, which is defined as an alias for the jQuery() method: jQuery( selector [, context] ) (Note: The other overloaded JQuery methods are not relevant.) http://api.jquery.com/jQuery/ All script examples relate to the following sample document: !DOCTYPE html body p id=1/p div p id=2/p /div /body JQuery results: (Note: All results are returned as instances of jQuery objects, which are indexable like an array) $(html) // returns [html] $(body) // returns [] $(+div) // returns [] $(body, document.documentElement) // returns [body] $(p, $(body)) // returns [p#1] $(p, $(div)) // returns [p#2] $(+div, $(#1)) // returns [div] $(p, div, $(body)) // returns [p#1, div] $(body, []) // returns [] $(body, null) // returns [body] $(body, undefined) // returns [body] $() // returns [] document.findAll() should support the same parameters as $() and return an equivalent result collection in the majority of cases. Likewise, document.find() should work the same way, but return only the first match. Where findAll() returns an empty collection, find() would return null. From the above, it's clear that in the new API, there are cases where :scope should be implied and cases where it should not. In cases where :scope is implied and there's no explicit combinator, a descendant combinator needs to be implied too. $(html) // returns [html] document.findAll(html) :scope cannot be implied here because html is the root element, so it wouldn't match if the selector was interpreted as :scope html. $(body) // returns [] document.findAll(body) $(+div) // returns [] document.findAll(+div) :scope needs to be implied to make a syntactically valid selectors, making them equivalent to :scopebody and :scope+div, respectively. But :scope cannot match the root element here because otherwise the first would return the body element as a match. $(body, document.documentElement) // returns [body] document.findAll(body, document.documentElement) Like the previous case, :scope needs to be implied. This time, however, it needs to match the specified element node. It also means that the second parameter must be able to accept an Element node. $(p, $(body)) // returns [p#1] document.findAll(p, $(body)) document.findAll(p, document.findAll(body)) This is the same as the previous case, except a collection of elements is passed instead of a single Element node. This is equivalent to :scopep, where :scope matches the elements in the collection. It should work regardless of the type of collection. In the first case, $() returns a numerically indexed JQuery object, the latter returns a yet to be defined Array-like structure. $(p, $(div)) // returns [p#2] document.findAll(p, document.findAll(div)) In this case, despite not beginning with a combinator, the presence of a reference node indicates that :scope with a descendant combinator should be implied, equivalent to :scope p. $(+div, $(#1)) // returns [div]
Re: [XHR] responseType json
I'd like to bring up an issue with the spec with regards to responseText + the new json responseType. Currently it is written that responseText should throw an exception if the responseType is not or text. I would argue that responseText should also return the plain text when the type is json. Take the scenario of debugging an application, or an application that has a Error Reporting feature; If XHR.response returns null, meaning the JSON payload was not successfully parsed and/or was invalid, there is no means to retrieve the plain text that caused the error. null is rather useless at that point. See my WebKit bug for more context: https://bugs.webkit.org/show_bug.cgi?id=73648 For legacy reasons, responseText and responseXML continue to work together despite the responseType that is set. In other words, a responseType of text still allows access to responseXML, and responseType of document still allows access to responseText. And it makes sense that this is so; if a strong-typed Document from responseXML is unable to be created, responseText is the fallback to get the payload and either debug it, submit it as an error report, etc. I would argue that json responseType would be more valuable if it behaved the same. Unlike the binary types (ArrayBuffer, Blob), json and document are backed by a plain text payload and therefore responseText has value in being accessible. If all we can get on a bad JSON response is null, I think there is little incentive for anyone to use the json type when they can use text and JSON.parse it themselves. Comments, questions, and flames are welcomed! Thanks, Jarred
Re: [XHR] responseType json
I'd like to bring up an issue with the spec with regards to responseText + the new json responseType. Currently it is written that responseText should throw an exception if the responseType is not or text. I would argue that responseText should also return the plain text when the type is json. Take the scenario of debugging an application, or an application that has a Error Reporting feature; If XHR.response returns null, meaning the JSON payload was not successfully parsed and/or was invalid, there is no means to retrieve the plain text that caused the error. null is rather useless at that point. See my WebKit bug for more context: https://bugs.webkit.org/show_bug.cgi?id=73648 For legacy reasons, responseText and responseXML continue to work together despite the responseType that is set. In other words, a responseType of text still allows access to responseXML, and responseType of document still allows access to responseText. And it makes sense that this is so; if a strong-typed Document from responseXML is unable to be created, responseText is the fallback to get the payload and either debug it, submit it as an error report, etc. I would argue that json responseType would be more valuable if it behaved the same. Unlike the binary types (ArrayBuffer, Blob), json and document are backed by a plain text payload and therefore responseText has value in being accessible. If all we can get on a bad JSON response is null, I think there is little incentive for anyone to use the json type when they can use text and JSON.parse it themselves. Comments, questions, and flames are welcomed! Thanks, Jarred
Re: [XHR] responseType json
On Sun, Dec 11, 2011 at 4:08 PM, Jarred Nicholls jar...@sencha.com wrote: A good compromise would be to only throw it away (and thus restrict responseText access) upon the first successful parse when accessing .response. I disagree. Even though conceptually, the spec says that you first accumulate text and then you invoke JSON.parse, I think we should allow for implementations that feed an incremental JSON parser as data arrives from the network and throws away each input buffer after pushing it to the incremental JSON parser. That is, in order to allow more memory-efficient implementations in the future, I think we shouldn't expose responseText for JSON. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Web IDL sequenceT and item() method
On 2011-12-11 13:55, Marcos Caceres wrote: On Fri, 09 Dec 2011 19:51:48 +0100, Glenn Adamsgl...@skynav.com (mailto:gl...@skynav.com) wrote: If the answer is that no item() method is implied, then does the use of sequenceT in these newer specs entail dropping this method (with respect to prior DOM specs)? I'm also unsure as to the purpose of sequence in practice. Perhaps some examples of expected usage would help a bit? I use it in Selectors API for the refNodes parameter, which needs to accept any collection of nodes, whether it be a NodeList, Array, jQuery object or any other generic numerically indexed object. e.g. These should all work var list = document.getElementsByTagName(section) document.querySelectorAll(:scopeh1, list) document.querySelectorAll(:scopeh1, $(section)) // JQuery $() document.querySelectorAll(:scopeh1, [elm1, elm2, elm3]) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [XHR] responseType json
On Mon, Dec 12, 2011 at 5:37 AM, Anne van Kesteren ann...@opera.com wrote: On Sun, 11 Dec 2011 15:44:58 +0100, Jarred Nicholls jar...@sencha.com wrote: I understand that's how you spec'ed it, but it's not how it's implemented in IE nor WebKit for legacy purposes - which is what I meant in the above statement. What do you mean legacy purposes? responseType is a new feature. And we added it in this way in part because of feedback from the WebKit community that did not want to keep the raw data around. I wasn't talking about responseType, I was referring to the pair of responseText and responseXML being accessible together since the dawn of time. I don't know why WebKit and IE didn't take the opportunity to use responseType and kill that behavior; don't ask me, I wasn't responsible for it ;) In the thread where we discussed adding it the person working on it for WebKit did seem to plan on implementing it per the specification: http://lists.w3.org/Archives/**Public/public-webapps/** 2010OctDec/thread.html#msg799http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/thread.html#msg799 Clearly not - shame, because now I'm trying to clean up the mess. In WebKit and IE =9, a responseType of , text, or document means access to both responseXML and responseText. I don't know what IE10's behavior is yet. IE8 could not have supported this feature and for IE9 I could not find any documentation. Are you sure they implemented it? I'm not positive if they did to be honest - I haven't found it documented anywhere. Given that Gecko does the right thing and Opera will too (next major release I believe) I do not really see any reason to change the specification. I started an initiative to bring XHR in WebKit up-to-spec (see https://bugs.webkit.org/show_bug.cgi?id=54162) and got a lot of push back. All I'm asking is that if I run into push back again, that I can send them your way ;) -- Anne van Kesteren http://annevankesteren.nl/ -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls
Re: [XHR] responseType json
On Mon, Dec 12, 2011 at 6:39 AM, Henri Sivonen hsivo...@iki.fi wrote: On Sun, Dec 11, 2011 at 4:08 PM, Jarred Nicholls jar...@sencha.com wrote: A good compromise would be to only throw it away (and thus restrict responseText access) upon the first successful parse when accessing .response. I disagree. Even though conceptually, the spec says that you first accumulate text and then you invoke JSON.parse, I think we should allow for implementations that feed an incremental JSON parser as data arrives from the network and throws away each input buffer after pushing it to the incremental JSON parser. That is, in order to allow more memory-efficient implementations in the future, I think we shouldn't expose responseText for JSON. I'm completely down with that. It still leaves an unsatisfied use case; but one that, after a nice weekend of relaxation, I no longer care about. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls
Re: [XHR] responseType json
On Mon, 12 Dec 2011 14:12:57 +0100, Jarred Nicholls jar...@sencha.com wrote: I started an initiative to bring XHR in WebKit up-to-spec (see https://bugs.webkit.org/show_bug.cgi?id=54162) and got a lot of push back. All I'm asking is that if I run into push back again, that I can send them your way ;) So a) thanks a lot for doing that and b) please do send them here. Discussing the XMLHttpRequest standard should happen here, not in bugs.webkit.org :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] responseType json
On 12/12/2011 03:12 PM, Jarred Nicholls wrote: On Mon, Dec 12, 2011 at 5:37 AM, Anne van Kesteren ann...@opera.com mailto:ann...@opera.com wrote: On Sun, 11 Dec 2011 15:44:58 +0100, Jarred Nicholls jar...@sencha.com mailto:jar...@sencha.com wrote: I understand that's how you spec'ed it, but it's not how it's implemented in IE nor WebKit for legacy purposes - which is what I meant in the above statement. What do you mean legacy purposes? responseType is a new feature. And we added it in this way in part because of feedback from the WebKit community that did not want to keep the raw data around. I wasn't talking about responseType, I was referring to the pair of responseText and responseXML being accessible together since the dawn of time. In case responseType is not set. If responseType is set, implementations can optimize certain things. I don't know why WebKit and IE didn't take the opportunity to use responseType responseType is a new thing. Gecko hasn't changed behavior in case responseType is not set. and kill that behavior; don't ask me, I wasn't responsible for it ;) In the thread where we discussed adding it the person working on it for WebKit did seem to plan on implementing it per the specification: http://lists.w3.org/Archives/__Public/public-webapps/__2010OctDec/thread.html#msg799 http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/thread.html#msg799 Clearly not - shame, because now I'm trying to clean up the mess. In WebKit and IE =9, a responseType of , text, or document means access to both responseXML and responseText. I don't know what IE10's behavior is yet. IE8 could not have supported this feature and for IE9 I could not find any documentation. Are you sure they implemented it? I'm not positive if they did to be honest - I haven't found it documented anywhere. Given that Gecko does the right thing and Opera will too (next major release I believe) I do not really see any reason to change the specification. I started an initiative to bring XHR in WebKit up-to-spec (see https://bugs.webkit.org/show_bug.cgi?id=54162) and got a lot of push back. All I'm asking is that if I run into push back again, that I can send them your way ;) -- Anne van Kesteren http://annevankesteren.nl/ -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls
Publishing XHR (level 1 and 2)...
Hi All - the CfCs to publish a WD of the new XHR [1] and a WG Note of the old XHR [2] resulted in different opinions expressed. We think it is important to provide a clear message (especially for those not closely following WebApps' related discussions) that: 1) the group agreed to stop working on the old XHR (effectively obsoleting the XHR CR); and 2) the group will continue work on the new XHR. As such, we will move forward this way: 1. Publish a WG Note of XHR in /TR/XMLHttpRequest1/. The Status section of the NOTE will use the same style as used in for the Web SQL Database Note [3] and include: 1) a warning re the work has stopped; and 2) a link to the new XHR spec. The XHR CR, the last version of the spec with a recorded agreement on the contents, will be used as the basis of the CR. 2. Publish a new WD of the new XHR spec in /TR/XMLHttpRequest/ and titled XMLHttpRequest Level 2. If the publications can be made pub ready by December 12, they will be published on December 15; otherwise the publication will be in January. -Chaals and Art [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1250.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1306.html [3] http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/#status-of-this-document -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Publishing XHR (level 1 and 2)...
One small typo correction below ... On 12/12/11 8:47 AM, ext Charles McCathieNevile wrote: Hi All - the CfCs to publish a WD of the new XHR [1] and a WG Note of the old XHR [2] resulted in different opinions expressed. We think it is important to provide a clear message (especially for those not closely following WebApps' related discussions) that: 1) the group agreed to stop working on the old XHR (effectively obsoleting the XHR CR); and 2) the group will continue work on the new XHR. As such, we will move forward this way: 1. Publish a WG Note of XHR in /TR/XMLHttpRequest1/. The Status section of the NOTE will use the same style as used in for the Web SQL Database Note [3] and include: 1) a warning re the work has stopped; and 2) a link to the new XHR spec. The XHR CR, the last version of the spec with a recorded agreement on the contents, will be used as the basis of the CR. s/basis of the CR/basis of the WG Note/ 2. Publish a new WD of the new XHR spec in /TR/XMLHttpRequest/ and titled XMLHttpRequest Level 2. If the publications can be made pub ready by December 12, they will be published on December 15; otherwise the publication will be in January. -Chaals and Art [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1250.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1306.html [3] http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/#status-of-this-document
Re: Publishing XHR (level 1 and 2)...
On Mon, 12 Dec 2011 14:47:06 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi All - the CfCs to publish a WD of the new XHR [1] and a WG Note of the old XHR [2] resulted in different opinions expressed. We think it is important to provide a clear message (especially for those not closely following WebApps' related discussions) that: 1) the group agreed to stop working on the old XHR (effectively obsoleting the XHR CR); and 2) the group will continue work on the new XHR. As such, we will move forward this way: 1. Publish a WG Note of XHR in /TR/XMLHttpRequest1/. The Status section of the NOTE will use the same style as used in for the Web SQL Database Note [3] and include: 1) a warning re the work has stopped; and 2) a link to the new XHR spec. The XHR CR, the last version of the spec with a recorded agreement on the contents, will be used as the basis of the CR. Err, we meant the CR will be the basis of the Note. :( 2. Publish a new WD of the new XHR spec in /TR/XMLHttpRequest/ and titled XMLHttpRequest Level 2. If the publications can be made pub ready by December 12, they will be published on December 15; otherwise the publication will be in January. -Chaals and Art [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1250.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1306.html [3] http://www.w3.org/TR/2010/NOTE-webdatabase-20101118/#status-of-this-document -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Proposed Specification for find/findAll/matches
Thanks for doing the work here, Lachlan! This appears to be an
excellent summary of the discussion and a consistent proposal.
On Mon, Dec 12, 2011 at 3:07 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
6. *Proposed IDL*
interface NodeSelector {
Element find(DOMString selectors, optional Element refElement);
Element find(DOMString selectors, sequenceNode? refNodes);
??? findAll(DOMString selectors, optional Element refElement);
??? findAll(DOMString selectors, sequenceNode? refNodes);
};
Document implements NodeSelector;
DocumentFragment implements NodeSelector;
Element implements NodeSelector;
This extends the same interface as that the existing querySelector methods
use, which will make the methods available on elements, documents and
fragments.
Open Issues:
1. The return type for findAll is yet to be decided. It may be the
proposed NodeArray, a regular Array or something else.
It really needs to be NodeArray or whatever, so we can hang
.find/All() and many other useful methods off of it.
2. These new methods for Element may be split out to a separate
interface that omits the refElements and and refNodes parameters.
I'd agree with this. Given that the refs are ignored on Element,
there's no reason to keep them in the IDL; it'll just be confusing.
3. Do we need both find() and findAll(), or should we only have a
single new method that returns a collection?
I'm still slightly for only having the single method that returns a
collection, but the original arguments for having a single-node
version still hold (efficiency, etc.), and many people still want it,
so I'm fine with it.
Additionally, matchesSelector() will simply be renamed to matches().
With the detail (specified below) that it'll imply scope the same way
that .find() does, this is excellent.
Open Issue: Should findAll() and find() throw SYNTAX_ERR or return empty
collection and null, respectively?
No opinion on this. I've never used in jQuery. I assume it can be
used when you've built a selector in a switch or if-chain, and one of
the cases is just use the same elements again. However, in our
method you can just use :scope for that, so it doesn't seem
necessary to support it with the empty-string case as well.
Your :scope prepending rules look good as well.
~TJ
Re: [XHR] responseType json
On Mon, Dec 12, 2011 at 9:28 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/12/11 8:12 AM, Jarred Nicholls wrote:
I started an initiative to bring XHR in WebKit up-to-spec (see
https://bugs.webkit.org/show_**bug.cgi?id=54162https://bugs.webkit.org/show_bug.cgi?id=54162)
and got a lot of push
back.
That seems to be about a different issue than responseType, right?
I just tried the following testcase:
script
var xhr = new XMLHttpRequest();
xhr.open(GET, window.location, false);
xhr.responseType = document
xhr.send();
try { alert(xhr.responseText); } catch (e) { alert(e); }
try { alert(xhr.responseXML); } catch (e) { alert(e); }
xhr.open(GET, window.location, false);
xhr.responseType = text
xhr.send();
try { alert(xhr.responseText); } catch (e) { alert(e); }
try { alert(xhr.responseXML); } catch (e) { alert(e); }
/script
Gecko behavior seems to be per spec: the attempt to get responseText fails
on the first XHR, and the attempt to get responseXML fails on the second
XHR.
WebKit (tested Chrome dev channel and Safari 5.1.1 behavior) seems to be
partially per spec: the attempt to get responseText throws for the first
XHR, but the attempt to get the responseXML succeeds for the second XHR.
That sort of makes sense in terms of how I recall WebKit implementing
feeding data to their parser in XHR, if the implementation of responseType
just wasn't very careful.
There's no feeding (re: streaming) of data to a parser, it's buffered until
the state is DONE (readyState == 4) and then an XML doc is created upon the
first access to responseXML or response. Same will go for the JSON parser
in our first iteration of implementing the json responseType.
Given that WebKit already implements the right behavior when responseType
= document, it sounds like the only bug on their end here is really
responseType = text handling, right? It'd definitely be good to just fix
that...
Yeah I'm going to clean up all the mess.
-Boris
Thanks!
--
*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
HTML Speech XG Completes, seeks feedback for eventual standardization
Dear WebApps people, The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as an aid to developing full standards in this space. Whether the W3C work happens in a new Working Group or an existing one, we are interested in collecting feedback on the Incubator Group's work. We are specifically interested in input from the members of the WebApps Working Group. If you have any feedback to share, please send it to, or cc, the group's mailing list (public-xg-htmlspe...@w3.org). This will allow comments to be archived in one consistent location for use by whatever group takes up this work. Dan Burnett, Co-Chair HTML Speech Incubator Group [1] charter: http://www.w3.org/2005/Incubator/htmlspeech/charter [2] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ p.s. This feedback request is being sent to the following groups: WebApps, HTML, Audio, DAP, Voice Browser, Multimodal Interaction
