[From-Origin] on theft
I would suggest not using the word theft, even if placed in quotes. Call it bandwidth leeching or something like that. It certainly is by no means theft by any reasonable definition. theft |θeft|nounthe action or crime of stealing : he was convicted of theft | the latest theft happened at a garage. leech 1 |lē ch |verb [ intrans. ]habitually exploit or rely on : he's leeching off the kindness of others. G. On Fri, Jul 22, 2011 at 9:08 AM, Anne van Kesteren ann...@opera.com wrote: The WebApps WG published the From-Origin header proposal as FPWD: http://www.w3.org/TR/from-**origin/ http://www.w3.org/TR/from-origin/
[From-Origin] on clickjacking
Under the description of clickjacking, appears causing harm to visitor; however, there is no indication of how this may cause such harm. Please elaborate or refer to an external document that elaborates. G.
[From-Origin] on privacy leakage
The description of privacy leakage doesn't elaborate the issue sufficiently. I'd suggest adding a reference to a more complete, external document that discusses this in detail. G.
Re: Reference to the HTML specification
On Fri, Aug 5, 2011 at 7:36 AM, Arthur Barstow art.bars...@nokia.comwrote: On 8/5/11 8:50 AM, ext Philippe Le Hegaret wrote: On Fri, 2011-08-05 at 08:22 -0400, Arthur Barstow wrote: On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote: Several documents in the WebApps Working Group are linking to HTML, more specifically to the WHATWG HTML specification. An example of those is Progress Events. This is done for no reason than political as far as I can tell. This undermines and is disrespectful the work of the HTML Working Group. Unless the WebApps comes up with a set of good reasons of why this is done and convince the HTML Working Group, those references must be changed in order to publish the documents properly and respect the work of the HTML Working Group, Philippe, Re the specific case of the Progress Events spec - when it was last published it included non-normative references to both version of HTML: http://www.w3.org/TR/progress-**events/#referenceshttp://www.w3.org/TR/progress-events/#references May we do that again? (I interpret that to mean the W3C has a fixed version of HTML and the WHATWG has a tip-of-the-tree version of HTML and as such, I don't think it 'disses the HTMLWG nor the W3C.) Again, what are the reasons to link to the WHATWG HTML version? What does it mean for the work of the HTML Working Group? There are features in the WHATWG version that got rejected in the HTML Working Group. I agree with the requirement for a single normative reference for HTML and that it should be the HTMLWG's version. I agree. The W3C HTMLWG is the only reference that is viable as far as the larger standards community is concerned, and as far as Samsung is concerned. Perhaps it is acceptable to reference WHATWG versions as an expedient in the near term, however, that should be avoided unless there is no alternative. Glenn (speaking as Samsung rep. to WebApps WG)
Re: Reference to the HTML specification
On Mon, Aug 8, 2011 at 3:36 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Fri, Aug 5, 2011 at 7:43 PM, Charles Pritchard ch...@jumis.com wrote: On 8/5/2011 9:23 AM, Marcos Caceres wrote: It should be left to the editor's (or working group) discretion as to which spec they cite regardless of the reason. And one of the role of the W3C staff is to ensure proper coordination between the various Working Groups at the W3C. I'm pointing out we are being inconsistent, I'm still not sure what the problem is. It seems like the problem is that some people feel the citing a WHATWG spec is disrespectful of the HTML WG. I think we should get on with making the best possible technology for our fellow humans and not get so caught up with who is There have been chair decisions which the WHATWG does not follow, many of them having to do with accessibility requirements. By continuing to link to the WHATWG spec as a primary source, during such fractures in consensus, it undermines the decision processes of the w3c. I thought that the WHATWG is an independent consortium; if so, it has no obligation to follow any decisions made by the HTML-WG. -- Marcos Caceres http://datadriven.com.au As far as I'm aware, the WHATWG is an *unincorporated association*, cf. http://en.wikipedia.org/wiki/Voluntary_association. As such, it does not enjoy the status of being a legal entity. Nobody has an obligation to follow the decisions of the HTML-WG; however, standards are only as useful as they are adopted, not only from a de facto but also a de jure perspective. The status of HTML5 w.r.t. the WHATWG will be completely irrelevant with respect to established, de jure Standards Development Organizations. If the WHATWG were to become a legal entity and be accredited by an international or national standards body, then that would change. The entire world of standards bodies and formal industry consortia recognize the authority of the W3C with respect to publishing formal standards for HTML, including HTML5. They do NOT recognize the authority of the WHATWG. In reality, at this point in time, the WHATWG is no more than a drafting group that is feeding the W3C HTML WG with material. As such, the authority of the latter takes precedence over the former in the minds of all formal customers of HTML5. Of course, individuals (including corporations) may decide to favor the positions of the WHATWG, but that will not affect the formal, public position of international, national, and industry specific standards and specifications organizations, who will favor the W3C. Regards, Glenn Adams
Re: Reference to the HTML specification
On Wed, Aug 10, 2011 at 8:43 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Wed, Aug 10, 2011 at 4:19 PM, Glenn Adams gl...@skynav.com wrote: As far as I'm aware, the WHATWG is an unincorporated association, cf. http://en.wikipedia.org/wiki/Voluntary_association. As such, it does not enjoy the status of being a legal entity. Maybe not, but this is very legally real: © Copyright 2004-2011 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA. That has no bearing on the status of WHATWG as an entity. Personally, I find it very troubling that this (or any) particular set of corporations is (from all appearances) attempting to wrest control of HTML standardship from the W3C. I can't imagine this will be good for the health of the HTML community. Nobody has an obligation to follow the decisions of the HTML-WG; however, standards are only as useful as they are adopted, not only from a de facto but also a de jure perspective. The status of HTML5 w.r.t. the WHATWG will be completely irrelevant with respect to established, de jure Standards Development Organizations. If the WHATWG were to become a legal entity and be accredited by an international or national standards body, then that would change. Perhaps. The entire world of standards bodies and formal industry consortia recognize the authority of the W3C with respect to publishing formal standards for HTML, including HTML5. They do NOT recognize the authority of the WHATWG. I guess history will be the judge of that, specially as to which version _actually_ gets implemented by browsers (and which version engineers are actually referring to as they are implementing). In reality, at this point in time, the WHATWG is no more than a drafting group that is feeding the W3C HTML WG with material. I think it might be the other way around, specially as the WHATWG spec is more complete and contains more new stuff. As such, the authority of the latter takes precedence over the former in the minds of all formal customers of HTML5. Depends on who the consumers are. The industry I work with, which is the consumer electronics industry, and particularly Television related devices (set-top boxes, TVs, DVRs, BluRay Players, etc), including standards and compliance certification organizations, e.g., CEA, SCTE, SMPTE, DLNA, ISO, ITU, etc., will reference the W3C work, and not the WHATWG work. Engineers working in this industry will do likewise. Any divergence of implementations from the W3C published specs will be viewed as non-compliant, notwithstanding what is stated in WHATWG drafts. Of course, individuals (including corporations) may decide to favor the positions of the WHATWG, but that will not affect the formal, public position of international, national, and industry specific standards and specifications organizations, who will favor the W3C. That's fine; the W3C does provide a seal of quality and IPR assurances - but the work will continue in both places regardless. If the WHATWG were to publish a formal set of compliance testing content, procedures, etc., that covered all the functionality it has undertaken to define, then it would be assigned a higher status than the W3C in this regard. At this point, I do not expect the W3C to go quite this far; however, it will be necessary for the HTML-WG to at least define some test suites to cover W3C process requirements. As such, that gives it a more credible formal status within the industry I work. Regards, Glenn
Re: Reference to the HTML specification
thanks for your comment Karl, i have no further contribution on this subject; in any case, I am not a member of the AC list; regards, glenn On Wed, Aug 10, 2011 at 9:23 AM, Karl Dubost ka...@opera.com wrote: If I may… this discussion about the merits, status, etc of the two organizations should happen either on www-archive or AC list. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: TAG Comment on
Could you quantify widely? On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.com wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility. Adam On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohn n...@arcanedomain.com wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
Re: TAG Comment on
Perhaps. But widely implemented does not necessarily imply widely used. In any case, support for or use of a feature of a WD or CR does not imply it must be present in REC. On Tue, Nov 15, 2011 at 5:21 PM, art.bars...@nokia.com wrote: * From:* ext Glenn Adams [gl...@skynav.com] * * Could you quantify widely? I think this definition of widely used is useful for this context: http://caniuse.com/#search=storage Personally, I see little to negative value in ignoring the fact the ship has sailed for this spec. -AB On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.com wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility.
Re: Dropping XMLHttpRequest 1 (just do 2)?
Are you suggesting that the link [1] be changed to forward or refer to the new XHR2 work? [1] http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/ If so, then that would be a problem. On Wed, Nov 23, 2011 at 9:59 AM, Giuseppe Pascale giusep...@opera.comwrote: well, what I was asking is to make sure that if I go to xhr1 I actually find 2 Anyway I think this is what marcos and anne were saying, so fine.
Re: CfC: publish WG Note of the old XHR(1); deadline December 8
It is not possible to have only one XHR document. There is already a published CR for XHR1, which will always remain at [1]. [1] http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/ The question is what to do with that branch. Moving [1] to a WG Note would help resolve confusion about the status of that branch, not create more confusion. The summary section of the note could clearly explain the status of that work, and how it is to be superseded by the new XHR2 work. I support publishing the note. G. On Thu, Dec 1, 2011 at 4:33 PM, Marcos Caceres w...@marcosc.com wrote: On Thursday, 1 December 2011 at 19:25, Arthur Barstow wrote: Adrian proposed the old XHR(1) spec be published as a WG Note (to clearly state work on that spec has stopped) and this is a Call for Consensus to do so. I object to doing so. It will just cause more confusion. Please lets only have one XHR document (and not an additional Note). If everyone just sticks to the story (which is very logical), then there should be no need for confusion: it's not that hard to explain and it's the merger is in everyone's best interest.
Re: [XHR] responseType json
What do you mean by treat content that clearly is UTF-32 as UTF-16-encoded? Do you mean interpreting it as a sequence of unsigned shorts? That would be a direct violation of the semantics of UTF-32, would it not? I'm not advocating the use of UTF-32 for interchange, but it does have the advantage of being fixed length encoding covering the entirety of Unicode. On Sun, Dec 4, 2011 at 1:41 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Henri Sivonen wrote: Browsers don't support UTF-32. It has no use cases as an interchange encoding beyond writing evil test cases. Defining it as a valid encoding is reprehensible. If UTF-32 is bad, then it should be detected as such and be rejected. The current idea, from what I can tell, is to ignore UTF-32 exists, and treat content that clearly is UTF-32 as UTF-16-encoded, which is much worse, as some components are likely to actually detect UTF-32, they would disagree with other components, and that tends to cause strange bugs and security issues. Thankfully, that is not a problem in this particular case.
Re: [XHR] responseType json
In the example you give, there is consistency between the content metadata (charset param) and the content itself (as determined by sniffing). So why would both the metadata and content be ignored? If there were an inconsistency (but there isn't) then [1] would apply, in which case the metadata can't be ignored without user consent. [1] http://www.w3.org/TR/webarch/#metadata-inconsistencies In any case, what is suggested below would be a direct violation of [2] as well. [2] http://www.w3.org/TR/charmod/#C030 On Mon, Dec 5, 2011 at 8:20 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Glenn Adams wrote: What do you mean by treat content that clearly is UTF-32 as UTF-16-encoded? Do you mean interpreting it as a sequence of unsigned shorts? That would be a direct violation of the semantics of UTF-32, would it not? Consider you have ... Content-Type: example/example;charset=utf-32 FF FE 00 00 ... Some would like to treat this as UTF-16 encoded document starting with U+ after the Unicode signature, even though it clearly is UTF-32. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [XHR] responseType json
Let me choose my words more carefully. A browser may recognize UTF-32 (e.g., in a sniffer) without supporting it (either internally or for transcoding into a different internal encoding). If the browser supports UTF-32, then step (2) of [1] applies. [1] http://dev.w3.org/html5/spec/Overview.html#determining-the-character-encoding But, if the browser does not support UTF-32, then the table in step (4) of [1] is supposed to apply, which would interpret the initial two bytes FF FE as UTF-16LE according to the current language of [1], and further, return a confidence level of certain. I see the problem now. It seems that the table in step (4) should be changed to interpret an initial FF FE as UTF-16BE only if the following two bytes are not 00. On Mon, Dec 5, 2011 at 11:45 AM, Glenn Maynard gl...@zewt.org wrote: On Mon, Dec 5, 2011 at 1:00 PM, Glenn Adams gl...@skynav.com wrote: [2] http://www.w3.org/TR/charmod/#C030 No, it wouldn't. That doesn't say that UTF-32 must be recognized. You misread me. I am not saying or supporting that UTF-32 must be recognized. I am saying that MIS-recognizing UTF-32 as UTF-16 violates [2]. It's impossible to violate that rule if the encoding isn't recognized. When an IANA-registered charset name *is recognized*; UTF-32 isn't recognized, so this is irrelevant. If a browser doesn't support UTF-32 as an incoming interchange format, then it should treat it as any other character encoding it does not recognize. It must not pretend it is another encoding. When an encoding is not recognized by the browser, the browser has full discretion in guessing the encoding. (See step 7 of http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding.) It's perfectly reasonable for UTF-32 data to be detected as UTF-16. For example, UTF-32 data is likely to contain null bytes when scanned bytewise, and UTF-16 is the only supported encoding where that's likely to happen. Steps 7 and 8 gives browsers unrestricted freedom in selecting the encoding when the previous steps are unable to do so; if they choose to include if the charset is declared as UTF-32, return UTF-16 as one of their autodetection rules, the spec allows it. -- Glenn Maynard
Re: [XHR] responseType json
The problem as I see it is that the current spec text for charset detection effectively *requires* a browser that does not support UTF-32 to explicitly ignore content metadata that may be correct (if it specifies UTF-32 as charset param), and further, to explicitly mis-label such content as UTF-16LE in the case that the first four bytes are FF FE 00 00. Indeed, the current algorithm requires mis-labelling such content as UTF-16LE with a confidence of certain. The current text is also ambiguous with respect to what support means in step (2) of Section 8.2.2.1 of [1]. Which of the following are meant by support? - recognize with sniffer - be capable of using directly as internal coding - be capable of transcoding to internal coding [1] http://dev.w3.org/html5/spec/Overview.html#determining-the-character-encoding On Mon, Dec 5, 2011 at 3:10 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 5 Dec 2011, Glenn Adams wrote: I see the problem now. It seems that the table in step (4) should be changed to interpret an initial FF FE as UTF-16BE only if the following two bytes are not 00. The current text is intentional. UTF-32 is explicitly not supported by the HTML standard. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Web IDL sequenceT and item() method
Hi Cameron, Does the ECMAScript binding for the IDL sequenceT type imply the existence of an item() method as a element accessor, where an element is a property whose property name is an array index? If so, then could describe how it is implied? The reason I ask is because I'm wondering about compatibility with earlier DOM specs, e.g., NodeList, CSSRuleList, etc., where an explicit item() method is defined, and which, in recent newer specifications based on Web IDL, has been re-expressed in terms of sequenceT. In my review of ECMA 262 3rd and 5th editions, I don't see an explicit mention of an item() method on Array objects (or their prototype), which are the ECMAScript binding for IDL sequenceT. 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)? Regards, Glenn
Re: Web IDL sequenceT and item() method
In DOM-4 WD, NodeList is now defined as an interface, and not using sequenceT. [1] [1] http://www.w3.org/TR/domcore/#interface-nodelist From what I can tell, WebIDL sequenceT does not entail providing an item() method, which effectively makes it unusable for any of the pre-existing DOM interfaces with ECMAScript bindings. It may be worth modifying WebIDL to generate an item() method in its ECMAScript binding. On Sun, Dec 11, 2011 at 8:21 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/11/11 7:21 AM, Anne van Kesteren wrote: The DOM specifications probably need to move back to using interface rather than sequence. I was hoping sequence would define the whole collection thing magically, but it never turned out that way. Still not quite sure what the real use case is for sequence. Last I checked, defining an interface that takes an in parameter that can be a nodelist or JS Array of nodes needs to use sequence, no? Or am I confusing it with array again? -Boris
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
+1 for Marcos' position. If the W3C performed compliance testing, then it would perhaps be more appropriate to reference specific versions, at least in a compliance test specification. However, the W3C has historically not defined compliance test specifications or perform compliance testing of either content, servers, or clients. Instead, external organizations that do have an interest in compliance have published compliance test specifications that do make reference to specific versions. I think this approach is more appropriate and more consistent with W3C practices. This provides a compromise between the W3C's need to innovate and author and device manufacturer needs to define a level of interoperability consistent with some compliance test specifications. Many (most?) authors don't particularly care about strict compliance. Only in certain industries and content domains is compliance assigned a high priority. Let W3C specs use non-specific references where it makes sense, and let other organizations (or even the W3C if desired) define separate specifications that map these non-specific references to specific references in the context of a specific compliance test specification. Regards, Glenn On Sun, Dec 18, 2011 at 12:31 PM, Marcos Caceres w...@marcosc.com wrote: On Sunday, December 18, 2011 at 5:45 PM, Leonard Rosenthol wrote: Undated references (what you are suggesting) has the MAJOR PROBLEM that it makes it DIFFICULT/IMPOSSIBLE to do validation of any product that claims conformance to a standard – since it's impossible to determine which version of each undated reference they used. That's a FEATURE, not a problem. Makes it inexcusable not to keep up with specs (same design built into HTML5, SVG, etc.). See also how this de-cupling worked for XML: http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0192.html http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0201.html Additionally, it makes interoperability difficult/impossible since you can have multiple valid conforming implementations BUT they don't actually interoperate due to changes between revisions (and algo changes would be a good example of such an interoperability issue). I don't see how that is possible: if your spec does not conform to /latest/, then you are non-conforming. If you were conforming yesterday, but a new version of the a spec comes out tomorrow, then you update your software to conform to the latest version. As an example, almost all Browsers are on a 6 week release cycle now: so it's quite inexcusable to expect to just conform to some dates draft and then expected to never have to update the software (i.e., conformance is an ongoing living process: specs are buggy, tests are buggy, and software is buggy… any of those can affect an conformance over time: the are all living things). Pretending that slapping a date on spec means anything is unhelpful (and actually harmful, because all specs contain bugs and hence must be continuously maintained). -- Marcos Caceres
Re: [widgets] How to divorce widgets-digsig from Elliptic Curve PAG?
conformance definitions are not compliance testing; i did not use the word conformance; there are (at least) four different, independent tasks here: 1. defining conformance specifications 2. defining compliance test specifications 3. performing certification (i.e., applying compliance test specifications to content, devices, etc) 4. licensing labels/brands (denoting successful certification) the W3C historically defines the first of these only; other organizations (not the W3C) have defined (2) and performed (3) and (4); i'm agreeing with Marcos and suggesting that W3C stick with (1), and to make references to both internal and external dependent specifications be non-specific (unversioned) when this makes sense, and (2) other organizations may define (2), perform (3), and license (4); in the process of defining (2), these organizations can map non-specific references to specific (versioned) references; in other words, I believe that the W3C's tasks do not necessarily have to include normatively defining specific concrete version mappings for dependent spec references; this can be accomplished in (2), which need not be done by the W3C (and indeed has not been done historically, i.e., defining the criteria for successful certification); cheers, G. On Mon, Dec 19, 2011 at 9:15 AM, Jean-Claude Dufourd jean-claude.dufo...@telecom-paristech.fr wrote: On 19/12/11 16:55 , Glenn Adams wrote: ...However, the W3C has historically not defined compliance test specifications or perform compliance testing of either content, servers, or clients... JCD: To name just the specs I know because I participated in writing them: - SVGT 1.2 appendix D: conformance criteria - CDF WICD 1.0 appendix C: conformance Then, two randomly selected RECs: - XML1.1 section 5 Conformance - XML Schema 2001 section 2.4 Conformance Or do you mean historically as in the early 90s ? I believe you are confusing certification which W3C never tried AFAIK, with conformance which is in all currently developed specs I have looked at. Best regards JC -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: Use Cases for Connectionless Push support in Webapps recharter
what are the qualitative differences (if any) between these three use cases? On Tue, Jan 3, 2012 at 5:51 PM, Bryan Sullivan bls...@gmail.com wrote: I had an action item to provide some use cases for the Webapps recharter process, related to the Push based on extending server-sent events topic at the last F2F (draft API proposal that was presented: http://bkaj.net/w3c/eventsource-push.html). The intent of the action item was to establish a basis for a Webapps charter item related to extending eventsource (or coming up with a new API) for the ability to deliver arbitrary notifications/data to webapps via connectionless bearers, as informationally described in Server-Sent Events (http://dev.w3.org/html5/eventsource/). Here are three use cases: 1) One of Bob’s most-used apps is a social networking webapp which enables him to remain near-realtime connected to his friends and colleagues. During his busy social hours, when he’s out clubbing, his phone stays pretty much connected full time, with a constant stream of friend updates. He likes to remain just as connected though during less-busy times, for example during the workday as friends post their lunch plans or other updates randomly. While he wants his favorite app to remain ready to alert him, he doesn’t want the app to drain his battery just to remain connected during low-update periods. 2) Alice is a collector, and is continually watching or bidding in various online auctions. When auctions are about to close, she knows the activity can be fast and furious and is usually watching her auction webapp closely. But in the long slow hours between auction closings, she still likes for her webapp to alert her about bids and other auction updates as they happen, without delay. She needs for her auction webapp to enable her to continually watch multiple auctions without fear that its data usage during the slow periods will adversely impact her profits. 3) Bob uses a web based real-time communications service and he wants to be available to his friends and family even when his application is not running. Bob travels frequently and it is critical for him to optimize data usage and preserve battery. Bob’s friends can call him up to chat using video/audio or just text and he wants to make sure they can reach him irrespective of what device and what network he is connected at any given time. Comments/questions? -- Thanks, Bryan Sullivan
Re: Use Cases for Connectionless Push support in Webapps recharter
good summary... perhaps if you label/title each use case with the following summaries, the intention will be more clear (I for one did not discern these three goals from the stated UC language) On Wed, Jan 4, 2012 at 6:50 PM, Charles Pritchard ch...@jumis.com wrote: a) Don't drain the battery. b) Don't waste bandwidth. c) Don't use the more expensive connection when a less expensive connection is also available. On Jan 4, 2012, at 6:38 PM, Glenn Adams gl...@skynav.com wrote: what are the qualitative differences (if any) between these three use cases? On Tue, Jan 3, 2012 at 5:51 PM, Bryan Sullivan bls...@gmail.com bls...@gmail.com wrote: I had an action item to provide some use cases for the Webapps recharter process, related to the Push based on extending server-sent events topic at the last F2F (draft API proposal that was presented: http://bkaj.net/w3c/eventsource-push.html http://bkaj.net/w3c/eventsource-push.html). The intent of the action item was to establish a basis for a Webapps charter item related to extending eventsource (or coming up with a new API) for the ability to deliver arbitrary notifications/data to webapps via connectionless bearers, as informationally described in Server-Sent Events ( http://dev.w3.org/html5/eventsource/ http://dev.w3.org/html5/eventsource/). Here are three use cases: 1) One of Bob’s most-used apps is a social networking webapp which enables him to remain near-realtime connected to his friends and colleagues. During his busy social hours, when he’s out clubbing, his phone stays pretty much connected full time, with a constant stream of friend updates. He likes to remain just as connected though during less-busy times, for example during the workday as friends post their lunch plans or other updates randomly. While he wants his favorite app to remain ready to alert him, he doesn’t want the app to drain his battery just to remain connected during low-update periods. 2) Alice is a collector, and is continually watching or bidding in various online auctions. When auctions are about to close, she knows the activity can be fast and furious and is usually watching her auction webapp closely. But in the long slow hours between auction closings, she still likes for her webapp to alert her about bids and other auction updates as they happen, without delay. She needs for her auction webapp to enable her to continually watch multiple auctions without fear that its data usage during the slow periods will adversely impact her profits. 3) Bob uses a web based real-time communications service and he wants to be available to his friends and family even when his application is not running. Bob travels frequently and it is critical for him to optimize data usage and preserve battery. Bob’s friends can call him up to chat using video/audio or just text and he wants to make sure they can reach him irrespective of what device and what network he is connected at any given time. Comments/questions? -- Thanks, Bryan Sullivan
Re: String to ArrayBuffer
On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell k...@google.com wrote: The StringEncoding proposal is the best path forward because it provides correct behavior in all cases. Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding I see the following problems after a cursory glance: 4) It says Browsers MAY support additional encodings. This is a huge non-interoperability loophole. The spec should have a small and fixed set of supported encodings that everyone MUST support and supporting other encodings should be a MUST NOT. In practice, it will be impractical if not impossible to enforce such a dictum MUST NOT support other encodings. Implementers will support whatever they like when it comes to character encodings, both for interchange, runtime storage, and persistent storage. Regarding use of the word support in the context of character encodings, it would be useful if folks would explicitly qualify support as applying to one of these three uses (interchange, runtime storage, persistent storage).
Re: String to ArrayBuffer
On Thu, Jan 12, 2012 at 10:10 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Thu, Jan 12, 2012 at 8:59 AM, Glenn Adams gl...@skynav.com wrote: On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell k...@google.com wrote: The StringEncoding proposal is the best path forward because it provides correct behavior in all cases. Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding I see the following problems after a cursory glance: 4) It says Browsers MAY support additional encodings. This is a huge non-interoperability loophole. The spec should have a small and fixed set of supported encodings that everyone MUST support and supporting other encodings should be a MUST NOT. In practice, it will be impractical if not impossible to enforce such a dictum MUST NOT support other encodings. Implementers will support whatever they like when it comes to character encodings, both for interchange, runtime storage, and persistent storage. Actually, such requirements often work relatively well. Many implementors recognize the pain caused by race-to-the-bottom support for random encodings. I speak of enforcement. Will there be test cases to check for support of a random encoding not included in a blessed list? I suspect not.
Re: Obsolescence notices on old specifications, again
I object to adding such notice until all of the proposed replacement specs reach REC status. G. On Mon, Jan 23, 2012 at 2:01 AM, Ms2ger ms2...@gmail.com wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/**Public/www-dom/2012JanMar/**0011.htmlhttp://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
Re: Obsolescence notices on old specifications, again
I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. G. On Mon, Jan 23, 2012 at 12:09 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Jan 23, 2012 at 12:06 PM, Glenn Adams gl...@skynav.com wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. Why? The real world of modern spec use and authoring is no longer tightly tied to reaching REC (or even CR or PR), and the current situation of outdated specs with no warnings, misleadingly presented as if they represent modern practice, repeatedly leads to both user and implementer confusion. I don't know if this is the right thing to do for all of the listed specs, but in general this is important to fix. -- Glenn Maynard
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 2:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Jan 23, 2012 at 12:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. We have repeated evidence that pretending these specs aren't obsolete and useless hurts web implementors and authors. We're targeting the web with our specs, so that's extremely relevant for us, more so than non-web industries dealing with personal regulatory issues. Ignoring the regulatory issues for a moment, the non-web industries harm themselves (or rather, the down-level authors writing content for the things those industries are producing) by attempting to use these obsolete specs as well, since they'll be producing things that don't match the public web. But really, the important thing is just that these specs are hurting the web, and our primary focus is the web. In my opinion, the poor progress (in terms of time) in obtaining closure on new specs (i.e., reaching REC status) is doing more harm than keeping mature specs on the book. Furthermore, the industry I work in is not something outside the web, but is part of the web. It is just a part of the web that tends to evolve more slowly, and, consequently, assigns more priority to creating and maintaining formally mature specs.
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 5:58 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Ms2ger wrote:I propose that we add a pointer to the contemporary specification to the following specifications: ... * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) ... As far as I am aware, CSSOM is an unmaintained and incomplete set of ideas, and what of it reflects actually implemented behavior and what may change tomorrow is anyone's best guess so that is clearly not a suitable replacement. As an FYI, the two CSSOM specs now have new co-editors, who are working towards publishing new WDs within the next month. On the other hand, this work contains innovations that remain immature and need further implementation activity and testing (as would be required by the normal maturation process in the W3C).
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 4:58 AM, Arthur Barstow art.bars...@nokia.comwrote: Ms2ger, Last September, some obsolescence text was added to the DOM 2 Views REC: [[ http://www.w3.org/TR/DOM-**Level-2-Views/#notice-20110922http://www.w3.org/TR/DOM-Level-2-Views/#notice-20110922 http://www.w3.org/TR/2000/REC-**DOM-Level-2-Views-20001113/http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/ *Document Status Update 2011-09-22*: This paragraph is informative. The concepts this document defines are obsolete. The 'document' and 'defaultView' attributes are defined in the HTML5 http://www.w3.org/TR/html5/ specification with simplified semantics. The Web Applications Working Group http://www.w3.org/2008/**webapps/http://www.w3.org/2008/webapps/ encourages implementation of these concepts as defined by HTML5. ]] I think the proponents for adding obsolescence text to the other RECs should make a specific proposal for each REC. I would support a notice akin to this, however, I am concerned about using the term obsolete without having a normative substitute/replacement to reference. I realize that the potential substitutes are not yet in REC status, and will take some time to get there, and that it is possible to add informative references to work in progress, but this doesn't quite satisfy my notion of what obsolete means.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 12:32 AM, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Jan 23, 2012 at 10:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. Which laws or regulations require compliance with some of the above-mentioned specs? Have bugs been filed on those laws and regulations? I am referring to laws, regulations, and formal processes adopted by various governments (e.g., U.S. and EU) and recognized international standards organizations (e.g., ITU). One does not file bugs against laws and regulations of this type. The industry I am referring to is television broadcast, cable, satellite, and broadband services, much of which is subject to national and international laws and regulations, some of which refer (directly or indirectly) to W3C RECs, including the DOM RECs being discussed here. With very few exceptions, the processes that govern these laws and regulations require that any externally referenced document be final, which, in the W3C process, means REC.
Re: Obsolescence notices on old specifications, again
I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same as saying DOM2 is a WIP. This is because the former can be read as saying that the normative content of DOM2 is now replaced with DOM4. I'm not sure what you mean by [DOM2] is a work on which progress has stopped. DOM2 is a REC, and is only subject to errata [1] and rescinding [2]. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind I'm not sure where the proposed obsolescence message falls in terms of [1] or [2]. Perhaps you could clarify, since presumably the process document will apply to any proposed change. On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 08:33 PM, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Not at all; it's a work on which progress has stopped long ago.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. It should be: DOM2 (a stale document) is obsolete. Use DOM4 (a work that is actively maintained). It would be more accurate perhaps to say that DOM4 is a work that is under active development. In the minds of most readers, maintenance is an errata process that follows completion (REC status). It doesn't demote DOM2 to a work in progress, because a work in progress is a step _up_ from where DOM2 is now. Many (most?) government, industry, and business activities that formally utilize W3C specifications would view a work in progress as less mature than a REC. That results in the form being assigned a lower value than the latter. So, yes, demote is the correct word. I understand your agenda is to reverse this way of thinking. I have no objection to that agenda per se. But it is not an agenda shared by many members of the W3C. If you think I'm wrong about this, then I'd like to see a poll or ballot that quantifies the membership's perspective on this issue.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org wrote: You keep saying this throughout this thread without pointing to specifics. It's impossible to argue with broad, sweeping generalizations like this. So far, you have yet to point to one concrete organization/statute that cares about REC status. Ojan, apparently you are not familiar with international or national standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I could give you a list of hundreds if you wish, all having encoded such rules into their formal processes.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 1:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/24/12 8:58 PM, Glenn Adams wrote: 2012/1/24 Ojan Vafai o...@chromium.org mailto:o...@chromium.org Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 That doesn't really work for me. What would work for me is something like: Although DOM Level 2 continues to be subject to Errata Management Except it's not. As far as I know, errata haven't been published for close to a decade now, and there are no plans to publish any. This in spite of known things that need errata. As long as the W3C Process Document [1] applies, DOM2 is subject to Errata Management until such a time as it is formally Rescinded. It matters not whether there are any plans to publish errata or not. [1] http://www.w3.org/2005/10/Process-20051014/
Re: Obsolescence notices on old specifications, again
Ian, I agree with the sentiment of your response (take DOM4 right now and publish it as a REC). And, were it not for the W3C Process Document, we might do just that. However, for the time being, we need to work within the process document. The best way to do that is attempt to (as rapidly as possible) obtain consensus on publishing DOM4 as a LC then quickly progress to CR. I personally (and the member I represent) will do whatever I (we) can to assist in that process. And the same applies for the other WIP DOM related specs. On Tue, Jan 24, 2012 at 1:15 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org wrote: You keep saying this throughout this thread without pointing to specifics. It's impossible to argue with broad, sweeping generalizations like this. So far, you have yet to point to one concrete organization/statute that cares about REC status. Ojan, apparently you are not familiar with international or national standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I could give you a list of hundreds if you wish, all having encoded such rules into their formal processes. I've no problem with providing stale snapshots for use by standards organisations and governments stuck with outdated models. That's fine. Nobody is saying that we should remove DOM2 altogether. Indeed, I've been arguing we should publish snapshots _more often_. I say we take DOM4 right now and publish it as a REC, and then do that every 6 months. That's the best way to serve organisations that need this artificial stability. The point is to make sure that people reading the stale documents know that that is what they are doing. That's why the proposal is merely to have a warning on the stale documents, not remove them altogether. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Obsolescence notices on old specifications, again
DOM2 was not created for the purpose of reflecting the behavior in popular implementations. So it would be misleading to use this rationale. I would suggest the more neutral language I proposed above: Although DOM Level 2 continues to be subject to Errata Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, it is no longer being actively maintained. Content authors and implementers are encouraged to consider the use of newer formulations of the Document Object Model, including DOM4 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance . I believe this avoids any misreadings and has the intended effect of warning authors/implementers about the status of DOM2 and its newer formulation in progress. On Tue, Jan 24, 2012 at 1:21 PM, Jonas Sicking jo...@sicking.cc wrote: I think the point that is most important to me to capture is that DOM2 no longer reflects the behavior in many browsers. So how about: DOM2 is no longer updated and doesn't in all cases reflect behavior in popular implementations. DOM4 is the latest actively maintained and updated version. link to DOM4 / Jonas 2012/1/24 Ojan Vafai o...@chromium.org: Can we just compromise on the language here? I don't think we'll find agreement on the proper way to do spec work. How about: DOM2 is no longer updated. DOM4 is the latest actively maintained version. link to DOM4 On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com wrote: I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same as saying DOM2 is a WIP. This is because the former can be read as saying that the normative content of DOM2 is now replaced with DOM4. I'm not sure what you mean by [DOM2] is a work on which progress has stopped. DOM2 is a REC, and is only subject to errata [1] and rescinding [2]. [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind I'm not sure where the proposed obsolescence message falls in terms of [1] or [2]. Perhaps you could clarify, since presumably the process document will apply to any proposed change. On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 08:33 PM, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. Not at all; it's a work on which progress has stopped long ago.
Re: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 1:26 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: Ian, I agree with the sentiment of your response (take DOM4 right now and publish it as a REC). And, were it not for the W3C Process Document, we might do just that. However, for the time being, we need to work within the process document. Actually, no, we don't. We're sentient beings, our adherence to bureaucratic protocols is entirely voluntary. Right. And last time I checked this is a W3C mailing list, a W3C group, and W3C documents under discussion. So presumably we sentient beings have at least implicitly signed up to the W3C Process (whether we agree with it or not). Let's not continue to belabor this thread though since, as you say, its beside the point. :)
Re: CfC: Charter addition for Fullscreen API
On Thu, Feb 2, 2012 at 11:37 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 31 Jan 2012 18:07:39 +0100, Arthur Barstow art.bars...@nokia.com wrote: On 1/31/12 11:04 AM, ext Robin Berjon wrote: We have a draft http://dvcs.w3.org/hg/**fullscreen/raw-file/tip/**Overview.htmlhttp://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html I'm pretty sure that I've seen implementer interest, and it's very obvious that there's a lot of developer interest in it. My understanding is that it has an editor. It would be good to get confirmation from Anne and/or Tantek. I'm fine with publishing this through WebApps. is there any reason this should be done as part of CSSOM View? i notice a to do listed at [1] as: - CSSOM should have a mechanism for taking elements full-screen [1] http://wiki.csswg.org/spec/cssom
Re: CfC: Charter addition for Fullscreen API
On Thu, Feb 2, 2012 at 4:14 PM, Anne van Kesteren ann...@opera.com wrote: On Fri, 03 Feb 2012 00:09:44 +0100, Glenn Adams gl...@skynav.com wrote: On Thu, Feb 2, 2012 at 11:37 AM, Anne van Kesteren ann...@opera.com wrote: I'm fine with publishing this through WebApps. is there any reason this should be done as part of CSSOM View? i notice a to do listed at [1] as: - CSSOM should have a mechanism for taking elements full-screen [1] http://wiki.csswg.org/spec/**cssom http://wiki.csswg.org/spec/cssom That was mostly because it was tangentially related (and at some point suggested to be put there), but now it's drafted as a separate document I think it's fine to keep it as such. ok, sounds good
Re: CfC by 02-14: Add IME API to the charter
will there be liaison/participation with I18N Core WG on this work? On Wed, Feb 8, 2012 at 5:29 AM, Charles McCathieNevile cha...@opera.comwrote: Hi, thanks to Mike and the Google guys, we have http://dvcs.w3.org/hg/ime-api/ **raw-file/default/use-cases/**Overview.htmlhttp://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.htmlwhich explains what an IME API would do and why it would be useful. I believe we have editors but it doesn't name a test facilitator (don't blame me, Art chose that as the name ;) ) and we need one. I am assuming that will be forthcoming, so this is a formal call for Consensus to add this item to the charter. Silence will be considered assent, positive response is preferred, and the deadline is the end of Tuesday 14th February. cheers Chaals -- 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: CfC by 02-14: Add IME API to the charter
thanks, i was just checking; i'll defer to Addison and the editor of the proposed work to handle the details On Wed, Feb 8, 2012 at 9:02 AM, Michael[tm] Smith m...@w3.org wrote: Hi Glenn, @2012-02-08 08:33 -0700: will there be liaison/participation with I18N Core WG on this work? I've already given Richard Ishida and Felix Sasaki a heads-up about it. I believe Richard is planning to propose an agenda item for it on the i18n WG call today. But anyway certainly there shall be active liaise-ing with i18n folk on this API. If you believe we need to capture that in the charter then I can work with the chairs to make sure we do that. --Mike -- Michael[tm] Smith http://people.w3.org/mike/+
Re: [webcomponents] Considering declarative event handlers
On Tue, Feb 7, 2012 at 12:41 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: To make Web Components more usable, I would like to consider providing a way to declare event handlers in markup. As I look over the use cases and try to implement them using the proposed syntax (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html), a pattern emerges, where a bunch of event handlers is declared and registered early in the lifecycle of the custom elements ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/samples/entry-helper.html , http://dglazkov.github.com/Tabs/tabs-control.js as rough examples). Is there a reason not to use (modifying as required) XML Events [1] for this purpose? [1] http://www.w3.org/TR/2003/REC-xml-events-20031014/
Re: IME API Use cases editorial feedback
On Wed, Feb 29, 2012 at 2:59 AM, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html SUN Haitao found the description of the Traditional Chinese IME used as an example in this use cases document somewhat inaccurate. 3.1.2 Radical composer __ # typing ‘o’ produces ‘人’ on a Traditional-Chinese (or Bopomofo) # keyboard s/Bopomofo/Changjie/ I would suggest Cangjie as the preferred spelling for 倉頡 (仓颉) [1]. [1] http://en.wikipedia.org/wiki/Cangjie_input_method (It's not clear to me if Changjie radicals are phonetic but I am totally ignorant on this subject) they are not phonetic, nor are they semantic; they are geometric only (as graphical mnemonics) 3.2 Converter _ # Bopomofo characters ‘人弓’ matches Traditional-Chinese # ideographic characters ‘乞’, ‘亿’, ‘亇’, etc. s/Bopomofo characters/Changjie components/ s/Changjie/Cangjie/ Cheers, Kenny
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan aranganat...@mozilla.comwrote: On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan aranganat...@mozilla.com wrote: Should the actual UTF-8 encoding algorithm be specified by HTML? I don't know, since I think that Unicode to UTF-8 is pretty common. Might help if it was part of the common infrastructure. what needs to be specified that isn't already found in Unicode [1], clause D92, p92ff? [1] http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Wed, Feb 29, 2012 at 2:58 PM, Arun Ranganathan aranganat...@mozilla.comwrote: On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan aranganat...@mozilla.com wrote: On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan aranganat...@mozilla.com wrote: Should the actual UTF-8 encoding algorithm be specified by HTML? I don't know, since I think that Unicode to UTF-8 is pretty common. Might help if it was part of the common infrastructure. what needs to be specified that isn't already found in Unicode [1], clause D92, p92ff? [1] http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf I think that gets us by. Do you think we need a reference in FileAPI? Or can we merely say to encode as UTF-8 and leave it to implementations (a reasonable assumption IMHO). I think you should have a reference. You could either use the following, as does HTML5: [RFC3629]UTF-8, a transformation format of ISO 10646http://tools.ietf.org/html/rfc3629, F. Yergeau. IETF. or you could modify the language in Section 4 Terminology and Algorithms to read: The terms and algorithms *UTF-8*, fragment, scheme, document, unloading document cleanup steps, event handler attributes, event handler event type, origin, same origin, event loops, task, task source, URL, and queue a task are defined by the HTML specification [HTMLhttp://dev.w3.org/2006/webapi/FileAPI/#HTML ]. HTML A conforming user agenthttp://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation MUST support at least the subset of the functionality defined in HTML that this specification relies upon; in particular, it must support event loopshttp://dev.w3.org/2006/webapi/FileAPI/#event-loops and event handler attributeshttp://dev.w3.org/2006/webapi/FileAPI/#event-handler-attributes. [HTML http://dev.w3.org/2006/webapi/FileAPI/#HTML]
Re: [FileAPI, common] UTF-16 to UTF-8 conversion
On Wed, Feb 29, 2012 at 3:43 PM, Glenn Adams gl...@skynav.com wrote: HTML A conforming user agenthttp://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation MUST support at least the subset of the functionality defined in HTML that this specification relies upon; in particular, it must support event loopshttp://dev.w3.org/2006/webapi/FileAPI/#event-loops and event handler attributeshttp://dev.w3.org/2006/webapi/FileAPI/#event-handler-attributes. [HTML http://dev.w3.org/2006/webapi/FileAPI/#HTML] Ignore the above paragraph.
Re: WebSockets -- only TCP?
RFC 6455 defines WSP as a TCP protocol [1] [1] http://tools.ietf.org/html/rfc6455#section-1.5 at present the WebSocket API is nothing more than a thin layer over WSP, and references WSP for all protocol bindings; there is no discarding of UDP involved; it simply is/was not a requirement driving WSP; if someone defines a new flavor of WSP in the future based on UDP, e.g., WSPU, then the WebSocket API could be updated to make reference to it; in conclusion, I don't see any cause to change the WebSocket API draft to explicitly suggest use of an alternative protocol (to WSP) since none exists at this time; On Thu, Mar 15, 2012 at 5:28 AM, Rick van Rein r...@openfortress.nl wrote: Hello, I would like to comment on the current (20120313) WebSockets specification. The text sounds to me like it implicitly assumes that all protocols are run over TCP. It could be said that the choice of URL makes it sufficiently general to include UDP (and possibly SCTP), but the usage of terms like connecting sends a hint to implementers that support of TCP would suffice. If the intention is to create a TCP-only WebSocket, then I think this should be made explicit. And if UDP would also be supported, then a remark around connection states that some apply only to connection-oriented URL protocols would send a clearer message to implementers. I do think UDP is too important to discard from WebSockets; among the things we can do with current technology (Flash or Java) is a softphone running in a browser; in a TCP-only HTML5 environment with deprecated support for these technologies such options would have no standing ground. I hope this is helpful feedback. Best wishes, Rick van Rein OpenFortress
Re: WebSockets -- only TCP?
no On Mon, Mar 19, 2012 at 1:09 AM, Rick van Rein r...@openfortress.nl wrote: Hello, See PeerConnection in http://dev.w3.org/2011/webrtc/editor/webrtc.html Ah, I was looking in the wrong place then :) Is this considered as part of the HTML5 specification?
informal survey - on spec philosophy
It has been stated to me that, at least for open web platform standards, the following statement is true and is shared by the majority: if it isn't written in the spec, it isn't allowed by the spec I happen to disagree with the truth of this, based on my personal experience both with spec writing and with implementation/use of specs, but I would be curious to see who agrees with this idea or not. The case in point is an instance of a possible ambiguity in a spec because a particular assumption/convention is not documented; i.e., an assumption that something isn't allowed even though it isn't explicitly disallowed. While I agree it is, in general, impossible (or at least impractical) to document all disallowances, I do believe it is important to document important disallowances, particular when there are concerns raised about spec ambiguity. Regards, Glenn
Re: informal survey - on spec philosophy
On Mon, Mar 26, 2012 at 2:46 PM, Marcos Caceres w...@marcosc.com wrote: On Monday, 26 March 2012 at 21:40, Glenn Adams wrote: It has been stated to me that, at least for open web platform standards, the following statement is true and is shared by the majority: if it isn't written in the spec, it isn't allowed by the spec Can you provide some examples of what you mean? This seems a little out of the blue? the spec phrase associated with can be interpreted as any of the following relations [1]: - injective and surjective (one-to-one and onto) - injective and non-surjective (one-to-one but not onto) - non-injective and surjective (not one-to-one but onto) - non-injective and non-surjective (not one-to-one and not onto) [1] http://en.wikipedia.org/wiki/Bijection,_injection_and_surjection it has been claimed that associated with means at least injective and perhaps also surjective, and that since the spec does not say it can be non-injective, then the last two could not apply; my position is that, unless somewhere it is documented what the convention associated with means, that it is (1) ambiguous, and (2) can be interpreted in any of the above four ways; this also goes to the issue of whether if it is not documented in the spec it is not allowed applies; my position is that if the spec is ambiguous (allows for multiple reasonable readings), then it is allowed (even though that may not have been the author's intent); I happen to disagree with the truth of this, based on my personal experience both with spec writing and with implementation/use of specs, but I would be curious to see who agrees with this idea or not. The case in point is an instance of a possible ambiguity in a spec because a particular assumption/convention is not documented; Which one? see above i.e., an assumption that something isn't allowed even though it isn't explicitly disallowed. While I agree it is, in general, impossible (or at least impractical) to document all disallowances, I do believe it is important to document important disallowances, particular when there are concerns raised about spec ambiguity. I guess it's a case by case thing. But generally, if the spec is written with a not in spec, not allowed state machine, then it would hold. there are two issues here: (1) whether the spec is ambiguous or not (permits multiple interpretations), and (2) whether there is an unwritten convention (if the spec doesn't say it then it is not allowed) that applies or not my position is that ambiguities should be avoided wherever possible and that important conventions should be documented; further, i'm not sure I would agree with a convention of if the spec doesn't say it then it is not allowed; or at least, that is the point of this thread, to see what others think...
Re: informal survey - on spec philosophy
On Mon, Mar 26, 2012 at 4:23 PM, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/03/27 5:43), Glenn Adams wrote: my position is that, unless somewhere it is documented what the convention associated with means, that it is (1) ambiguous, and (2) can be interpreted in any of the above four ways; This is still lacking context, but in general I agree with you. The specific context this came up in is [1]. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299 this also goes to the issue of whether if it is not documented in the spec it is not allowed applies; my position is that if the spec is ambiguous (allows for multiple reasonable readings), then it is allowed (even though that may not have been the author's intent); Agreed. (12/03/27 4:40), Glenn Adams wrote: It has been stated to me that, at least for open web platform standards, the following statement is true and is shared by the majority: if it isn't written in the spec, it isn't allowed by the spec What context was this statement in? For the spec for API A, you can't really write a test that asserts the non-existence of API B of course. A WebApps spec editor made this assertion to me if it isn't written in the spec, it isn't allowed by the spec. I did (do) not agree. I wondered what others think. The specific context is how to interpret associated with and whether it means one-to-one or not. Since the spec doesn't define associated with, I argue that it need not be interpreted as one-to-one. However, the editor argued that if the spec doesn't say that it can be interpreted as non-injective (not one-to-one), then this interpretation is not allowed.
Re: [xhr] statusText is underdefined
Is this really a problem? HTTP defines the form and encoding of the status text, and WebIDL/ES defines the form and encoding of DOMString. Adding an explicit conversion definition seems redundant and overspecified. I would argue the same for all other cases in the spec where it calls out an explicit (and unnecessary) conversion. On Tue, Mar 27, 2012 at 3:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: The spec says: Return the HTTP status text. But the HTTP status text is a sequence of bytes, while the return value for statusText is a DOMString. The conversion from one to the other needs to be defined. -Boris
Re: [xhr] statusText is underdefined
On Tue, Mar 27, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/27/12 2:46 PM, Glenn Adams wrote: Is this really a problem? Yes. We've run into bug reports in the past of sites sending some pretty random bytes in the HTTP status text, then reading .statusText from script. If we want interop here, we need to define the conversion. HTTP defines the form and encoding of the status text Except it doesn't, last I checked. Has that changed? RFC2616 states (on pages : Fielding, et al. Standards Track [Page 39] Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Fielding, et al. Standards Track [Page 40] Reason-Phrase = *TEXT, excluding CR, LF Fielding, et al. Standards Track [Page 15] The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. TEXT = any OCTET except CTLs, but including LWS This makes it pretty clear that Reason Phrase must use ISO-8859-1 (Latin1) unless it uses the encoded-word extension from RFC2047. If the latter is used, then a charset must be designated. Given this, I don't see any spec bug (though there may be implementation bugs in case the client side does not correctly implement the above HTTP requirements).
Re: [xhr] statusText is underdefined
On Tue, Mar 27, 2012 at 4:38 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/27/12 3:36 PM, Boris Zbarsky wrote: On 3/27/12 3:35 PM, Glenn Adams wrote: The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. I believe that does not actually match server reality, unfortunately... And one more thing. Even the text you quoted does not define what happens if the rules from RFC 2047 are followed incorrectly (e.g. declaring a UTF-8 encoding but then having byte sequences that are not valid UTF-8 in the data). The behavior needs to actually be defined here for all values of the status text, whichever spec that happens in. Since there are so may places in XHR, HTML5, etc., that interact with HTTP semantics, it would be better to define this in one place for all uses, and not attempt to redefine at every place where conversion to DOMString occurs. DRY.
Re: [xhr] statusText is underdefined
On Wed, Mar 28, 2012 at 1:33 AM, Julian Reschke julian.resc...@gmx.dewrote: On 2012-03-28 00:35, Glenn Adams wrote: On Tue, Mar 27, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 3/27/12 2:46 PM, Glenn Adams wrote: Is this really a problem? Yes. We've run into bug reports in the past of sites sending some pretty random bytes in the HTTP status text, then reading .statusText from script. If we want interop here, we need to define the conversion. HTTP defines the form and encoding of the status text Except it doesn't, last I checked. Has that changed? RFC2616 states (on pages : Fielding, et al. Standards Track [Page 39] Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Fielding, et al. Standards Track [Page 40] Reason-Phrase = *TEXT, excluding CR, LF Fielding, et al. Standards Track [Page 15] The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. TEXT =any OCTET except CTLs, but including LWS This makes it pretty clear that Reason Phrase must use ISO-8859-1 (Latin1) unless it uses the encoded-word extension from RFC2047. If the latter is used, then a charset must be designated. Given this, I don't see any spec bug (though there may be implementation bugs in case the client side does not correctly implement the above HTTP requirements). It's time to stop citing RFC 2616. Please have a look at http://greenbytes.de/tech/**webdav/draft-ietf-httpbis-p2-** semantics-19.html#rfc.section.**4http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.4 . Since 2616 is published and HTTPbis is not, I will go on citing it. Summary: HTTPbis does not attempt to define the character encoding anymore; if you use anything other than US-ASCII, you are on your own. RFC 2047 encoding never was used in practice, and has been removed. The right thing to do is the same as for header field values: use a US-ASCII compatible encoding that is most likely to work, and which is non-lossy, so a UTF-8 field value *can* be retrieved when needed. That encoding is ISO-8859-1. I'm not sure what you mean by citing ISO-8859-1 and UTF-8 in the same context. Please elaborate. (And HTTPBis doesn't talk about this because it defines octets on the wire, not an API). If HTTPbis doesn't define the character encoding of bytes on the wire when serializing reason status, then it leaves much to be desired.
Re: [xhr] statusText is underdefined
On Wed, Mar 28, 2012 at 2:33 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 27 Mar 2012 22:23:15 +0100, Boris Zbarsky bzbar...@mit.edu wrote: But the HTTP status text is a sequence of bytes, while the return value for statusText is a DOMString. The conversion from one to the other needs to be defined. Would using http://dvcs.w3.org/hg/xhr/raw-**file/tip/Overview.html#** inflate-a-byte-sequence-into-**a-domstringhttp://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#inflate-a-byte-sequence-into-a-domstringbe sufficient or is there something in particular we should do? Well, that would define a specific, definite algorithm. Never mind that it would introduce random bytes into DOMStrings that may or may not have anything to do with character data. I personally think a better solution is simply to dictate that reason status *always* be interpreted as ISO-8859-1, which would, in effect, make the inflate algorithm well defined; i.e., no longer simply random bytes.
Re: [xhr] statusText is underdefined
On Wed, Mar 28, 2012 at 3:50 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 28 Mar 2012 08:52:25 +0100, Glenn Adams gl...@skynav.com wrote: Well, that would define a specific, definite algorithm. Never mind that it would introduce random bytes into DOMStrings that may or may not have anything to do with character data. That's false. What is false? At present, the inflate algorithm does not make reference to any character encoding, so it just treats the data as bytes; therefore, it is *not* well defined when no character encoding is associated with the input byte sequence. Using iso-8859-1 is ambiguous as it is a common alias for windows-1252 which is definitely not what we want here. I'm not sure what you mean by ambiguous. If users/servers mislabel content as 8859-1 or if they insert non-8859-1 data into byte strings that are defined to be 8859-1, then that is a usage problem, not a spec problem. My point about introducing random bytes has to do with whether the inflate algorithm is employed as is or in conjunction with a normative statement about how to (semantically) interpret the input byte string (to the inflate algorithm). If we declare (normatively, in the spec) that it is 8859-1 then the algorithm and spec are now well defined. However, absent of declaring the encoding of the input byte string, the inflate algorithm output is not semantically known. I am assuming here that neither the inflate algorithm nor the (http) client is attempting to guess/sniff the encoding of the reason status string. Or are you suggesting otherwise?
Re: [xhr] statusText is underdefined
On Wed, Mar 28, 2012 at 4:48 AM, Julian Reschke julian.resc...@gmx.dewrote: On 2012-03-28 09:48, Glenn Adams wrote: I'm not sure what you mean by citing ISO-8859-1 and UTF-8 in the same context. Please elaborate. If you have UTF-8 on the wire and the client handles it as ISO-8859-1, the API user can extract the original octets from the string and re-decode from UTF-8. Of course that requires either heuristics or out-of-band information that this actually was UTF-8 in the first place. The problem I have with this is now you have DOMString serving as a container for an arbitrary byte string; i.e., no longer having any relation to a UTF-16 code unit sequence. Naive uses of DOMString should be able to assume it denotes UTF-16 encoded strings. Any use of DOMString to serve as a holder for arbitrary binary data (including inflating from UTF-8 bytes into 16-bit code units), should be specifically marked as such. Since the user authored content will need to know it is in fact not UTF-16 data. Let's call these two modes jekyll and hyde. When the inflate algorithm's input coding is not specified or known, then the output is a hyde mode DOMString, which is in fact not a character string, but merely an unsigned short[] array with no other semantics. It is certainly possible to define reasonStatus in this fashion, but if done this way, it should be made abundantly clear in the spec that this usage of DOMString is of they hyde variety, which has the effect of placing the burden of charset sniffing on the user defined code. This is certainly a possible strategy for XHR client implementations to use in order to deal with the mess of actual usage in the web (wherein the 8859 dictum was ignored).
Re: [xhr] statusText is underdefined
On Tue, Mar 27, 2012 at 3:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: The spec says: Return the HTTP status text. But the HTTP status text is a sequence of bytes, while the return value for statusText is a DOMString. The conversion from one to the other needs to be defined. If I may summarize: (1) although RFC2616 prescribes the use of 8859-1 for the on-the-wire representation of status text, this has not been followed in practice, and indeed, arbitrary character encodings are being used when serializing the reason status; (2) xhr client implementations have two options for exposing status text: - do not interpret status text in terms of character encoding; rather, simply expose the byte string to the user-defined code and leave encoding determination up to the user-defined code; - do interpret status text encoding, and convert to a semantically well defined character string, possibly requiring sniffing the serialized byte sequence; (3) in both of these options, it is possible to use DOMString to return the results: - in the first case, using what I have called hyde mode, the DOMString merely serves as an unsigned short[] for which the originally serialized byte sequence (of status text) is stuffed into the lower bytes (having no necessary relationship to a Unicode coded character sequence); - in the second case, using what I have called jekyll mode, the DOMString is interpreted (as normal) as a UTF-16 encoded Unicode string (corresponding to a well-defined Unicode coded character sequence); Is this a accurate summary? I agree that if the first option above is chosen, then the inflate algorithm is adequate. However, the specification text should make it abundantly clear that the hyde mode flavor of DOMString is being employed, and that the user defined code has the burden of decoding. As a web-content author and user, I would prefer that option #2 is adopted; or, if I were very particular, I would prefer that two accessors were provided: one for obtaining the raw input bytes (e.g., as a BLOB) and another for obtaining the client's best guess at a decoded Unicode string. In this latter case, I could make the decision on which to use. Overall, I could accept option #1 if the spec makes clear that hyde mode applies. G.
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote: On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. That's because they are not bound to any particular URI scheme. Just to some origin. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. As there are no interoperability issues, I don't agree the TWI spec needs to be updated any further. It's just a simple spec and any further clarifications would just be academic. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454 in that case, please record an objection on my part
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 9:04 AM, Glenn Adams gl...@skynav.com wrote: On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote: On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote: On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote: Marcos - would you please enumerate the CR's uses of HTML5 and state whether each usage is to a stable part of HTML5? 3. When getting or setting the preferences attribute, if the origin of a widget instance is mutable (e.g., if the user agent allows document.domain to be dynamically changed), then the user agent must perform the preference-origin security check. The concept of origin is defined in [HTML]. Origin is concept that is well understood - as is the same origin policy used by browsers. TWI [1] does not define the origin of a widget instance. That's because they are not bound to any particular URI scheme. Just to some origin. Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept of origin', given that it normatively refers to The Web Origin Concept [2]. TWI needs to be more specific about what aspect of Origin is being referenced and where that specific aspect is defined. As there are no interoperability issues, I don't agree the TWI spec needs to be updated any further. It's just a simple spec and any further clarifications would just be academic. [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/ [2] http://tools.ietf.org/html/rfc6454 in that case, please record an objection on my part just to be clear, I mean an objection to publishing as PR unless this is clarified; i believe this is an issue because the concept and use of origin is (1) very complex and (2) thus prone to misinterpretation; for example, it is not well recognized that HTML5 itself does not require a UA to send an Origin header in a URL request (see [3]) [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16574
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 9:49 AM, Marcos Caceres w...@marcosc.com wrote: On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote: On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote: in that case, please record an objection on my part just to be clear, I mean an objection to publishing as PR unless this is clarified; i believe this is an issue because the concept and use of origin is (1) very complex and (2) thus prone to misinterpretation; for example, it is not well recognized that HTML5 itself does not require a UA to send an Origin header in a URL request (see [3]) Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web Storage). But what does this have to do with Widgets? Glenn and I discussed this on IRC. Glenn suggested I add the following to the definition of a widget instance: The origin of a widget instance is the origin of the Document object associated with the widget instance's browsing context. I agree with Glenns recommendation, so I've go ahead and added that: http://dev.w3.org/2006/waf/widgets-api/#widget-instance thanks Marcos, I drop my objection; regarding the reference to HTML5, it would be an improvement if you could change section 6.5 from: The concept of origin is defined in [HTML]http://dev.w3.org/2006/waf/widgets-api/#html5 . to The concept of origin of a Document object is defined in [HTML]http://dev.w3.org/2006/waf/widgets-api/#html5 .
Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation
On Thu, Apr 19, 2012 at 10:02 AM, Marcos Caceres marcosscace...@gmail.comwrote: On Thursday, 19 April 2012 at 16:57, Glenn Adams wrote: thanks Marcos, I drop my objection; regarding the reference to HTML5, Yay! :) it would be an improvement if you could change section 6.5 from: The concept of origin is defined in [HTML] ( http://dev.w3.org/2006/waf/widgets-api/#html5). to The concept of origin of a Document object is defined in [HTML] ( http://dev.w3.org/2006/waf/widgets-api/#html5). Done, and committed: http://dev.w3.org/2006/waf/widgets-api/#origin thanks for the speed of light resolution! :)
Re: Howto spec
On Wed, May 23, 2012 at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote: Hi, I have made some updates to the howto spec wiki page outlining how you should go about writing a specification, with some emphasis on specifications for APIs. http://wiki.whatwg.org/wiki/Howto_spec In particular the Patterns and Legacy DOM-style sections are probably of interest. I would love to have feedback to see what else people would like to see explained or how what is explained thus far can be done better. I would like to see more explanation of some statements under the Legacy DOM-style section, particularly: - what is the particular style of defining methods and attributes that is to be discouraged? - how does ReSpec.js use or promote the discouraged particulars?
Re: Howto spec
On Wed, May 23, 2012 at 9:55 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: This is neat! I especially appreciated the Method/Attribute patterns. I will use this. Should I be concerned about what seems to be a lively competition between ReSpec and Anolis. Do we need this tussle? Can we not just decide which tool to use? editor tools are at the editors' prerogative, so we should not mandate specific tools i think in fact, i am not completely happy with either respec or anolis, and have put together something of a hybrid i'm using on cssom*; in particular, what i'm doing is: - writing all IDL and related documentation in WebIDL format, with each top-level definition in a distinct file, while using 'Documentation' extended attributes in the WebIDL files that contains both substitution patterns and markup, rather akin to javadoc but with different substitution keywords that better pertain to the WebIDL usage context; - use a driver file with CPP includes, then running (gnu) CPP to create a single IDL resource for the subsequent processing - use robin's WebIDLParser.js [1] (via node.js) to validate and dump JSON representation of IDL - use Aria Stewart's (aredridel) HTML5.js parser [2] (via node.js) to parse then serialize with substitution replacement based on the JSON IDL, e.g., !--widl(MediaList)-- is replaced with an HTML5 representation of the MediaList IDL, !--widl-intro(MediaList)--, !--widl-attrs(MediaList)--, !--widl-methods(MediaList)--, etc., get the associated documentation - finally use anolis to perform other substitutions, toc generation, etc. the reason I'm doing this is because i prefer embedding documentation in IDL sources than embedding IDL in HTML sources; i also want to do all processing at authoring time, and not at load time via the ReSpec approach once i'm satisfied with this approach, i'll post it and document with a wiki in case some other editor wishes to use this method; but, again, i think which approach is used should be left to specific editors, since it affects their productivity cheers, glenn
Re: Howto spec
On Wed, May 23, 2012 at 11:29 AM, Glenn Adams gl...@skynav.com wrote: On Wed, May 23, 2012 at 9:55 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: This is neat! I especially appreciated the Method/Attribute patterns. I will use this. Should I be concerned about what seems to be a lively competition between ReSpec and Anolis. Do we need this tussle? Can we not just decide which tool to use? editor tools are at the editors' prerogative, so we should not mandate specific tools i think in fact, i am not completely happy with either respec or anolis, and have put together something of a hybrid i'm using on cssom*; in particular, what i'm doing is: - writing all IDL and related documentation in WebIDL format, with each top-level definition in a distinct file, while using 'Documentation' extended attributes in the WebIDL files that contains both substitution patterns and markup, rather akin to javadoc but with different substitution keywords that better pertain to the WebIDL usage context; - use a driver file with CPP includes, then running (gnu) CPP to create a single IDL resource for the subsequent processing - use robin's WebIDLParser.js [1] (via node.js) to validate and dump JSON representation of IDL - use Aria Stewart's (aredridel) HTML5.js parser [2] (via node.js) to parse then serialize with substitution replacement based on the JSON IDL, e.g., !--widl(MediaList)-- is replaced with an HTML5 representation of the MediaList IDL, !--widl-intro(MediaList)--, !--widl-attrs(MediaList)--, !--widl-methods(MediaList)--, etc., get the associated documentation - finally use anolis to perform other substitutions, toc generation, etc. the reason I'm doing this is because i prefer embedding documentation in IDL sources than embedding IDL in HTML sources; i also want to do all processing at authoring time, and not at load time via the ReSpec approach once i'm satisfied with this approach, i'll post it and document with a wiki in case some other editor wishes to use this method; but, again, i think which approach is used should be left to specific editors, since it affects their productivity cheers, glenn relevant links [1] https://github.com/darobin/webidl.js [2] https://github.com/aredridel/html5
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On Wed, Jul 11, 2012 at 10:52 AM, Edward O'Connor eocon...@apple.comwrote: Art wrote: As such, this is a Call for Consensus to publish a Candidate Recommendation of Web Sockets. Ship it! :) +1
Re: Lazy Blob
On Wed, Aug 1, 2012 at 9:44 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET,
{ Authorization: Basic DEADBEEF });
Everything is the same as the previous version but the method and some
headers can be set by enumerating the Object. I *think* that those are all
that would ever be needed.
We already have an API to allow scripts to make network requests: XHR.
Please don't create a new API that will end up duplicating all of that.
However this might be done, it should hang off of XHR.
Why restrict to XHR? How about WebSocket as data source?
Re: Lazy Blob
On Wed, Aug 1, 2012 at 10:46 AM, Florian Bösch pya...@gmail.com wrote: On Wed, Aug 1, 2012 at 6:40 PM, Glenn Adams gl...@skynav.com wrote: Why restrict to XHR? How about WebSocket as data source? Websockets support array buffers and therefore by extension any blob/file object. However as a stream oriented API websockets have no content aquisition, negotation, range and transfer semantics unless you prop those up by yourself as an application layer protocol. I'm questioning defining a LazyBlob that is solely usable with XHR. It would be better to have a more generic version IMO.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 11:13 AM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 6:51 PM, Glenn Adams gl...@skynav.com wrote:
I'm questioning defining a LazyBlob that is solely usable with XHR. It
would be better to have a more generic version IMO.
Websockets have no content semantics, therefore any lazy content
negotiating reader cannot deal with websockets unless an additional
application layer protocol and implementation on the server side is
introduced, something that does not exist for websockets otherwise. You
could for instance implement HTTP over websockets to get the content
semantics, and if your server gets a websocket request, it could be proxied
to a domain socket which happend to have a webserver listening which would
understand the HTTP request and deliver the resource/range.
Now instead of implementing HTTP over websockets over HTTP over sockets,
you could just use XHRs which implement HTTP over sockets. Which is why
generalising lazy readers to websockets does not make sense.
Given the Simple approach suggested by DAR:
partial interface BlobBuilder {
Blob getBlobFromURL (DOMString url);
};
Usage:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;);
I don't see why the following isn't feasible:
blob =
bb.getBlobFromURL(ws://specifiction.com/image/kitten.pnghttp://specifiction.com/kitten.png
)
Or, given the Using XHR for Options approach:
partial interface BlobBuilder {
Blob getBlobFromURL (XMLHttpRequest xhr);
};
Usage:
var bb = new BlobBuilder()
, xhr = new XMLHttpRequest();
xhr.open(GET, /kitten.png, true);
xhr.setRequestHeader(Authorization, Basic DEADBEEF);
var blob = bb.getBlobFromURL(xhr);
why one couldn't have:
partial interface BlobBuilder {
Blob getBlobFromURL (WebSocket ws);
};
var bb = new BlobBuilder()
, ws = new
WebSocket(ws://specifiction.com/imagehttp://specifiction.com/kitten.png
);
ws.onopen = function(){ws.send(kitten.png);}
var blob = bb.getBlobFromURL(ws);
Re: Lazy Blob
On Wed, Aug 1, 2012 at 12:03 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Aug 1, 2012 at 7:57 PM, Glenn Adams gl...@skynav.com wrote: blob = bb.getBlobFromURL(ws://specifiction.com/image/kitten.pnghttp://specifiction.com/kitten.png ) There is no application layer transfer protocol inherent in websockets. Requesting a resource does not have any inherent meaning other than that you are opening a channel onto /image/kitten.png. Whoever receives that request is free to respond to that however he likes. You would need to introduce an application layer content protocol on top of websockets, and introduce a default websocket server framework capable of understanding such content requests. You're not just extending lazy reading to websockets. You're putting the burden on yourself to also specify a completely new standard application layer protocol for transfer and range and acquisition of resources over websocket channels. So? Why should lazy blob be specific to HTTP specific semantics when an arbitrary URL is not specific to HTTP?
Re: Lazy Blob
On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams gl...@skynav.com wrote: So? Why should lazy blob be specific to HTTP specific semantics when an arbitrary URL is not specific to HTTP? So if you want to have a lazy reader on Websockets you have either: 1) respecify the websocket protocol to include content semantics for accessing resources defined by an URL and having a specified size OR 2) define an additional protocol on top of websockets, which websockets know nothing about, that allows a custom implementation at the server side to respond in a meaningful fashion to resource range requests. OR define a mechanism for LazyBlob that permits the injection of app specific code into the underlying LazyBlob reader loop.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 1:47 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams gl...@skynav.com wrote: So? Why should lazy blob be specific to HTTP specific semantics when an arbitrary URL is not specific to HTTP? So if you want to have a lazy reader on Websockets you have either: 1) respecify the websocket protocol to include content semantics for accessing resources defined by an URL and having a specified size OR 2) define an additional protocol on top of websockets, which websockets know nothing about, that allows a custom implementation at the server side to respond in a meaningful fashion to resource range requests. OR define a mechanism for LazyBlob that permits the injection of app specific code into the underlying LazyBlob reader loop. Further, a default behavior in the absence of such an injection might be defined simply to read data from the WS and stuff into the blob.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 1:54 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Aug 1, 2012 at 9:50 PM, Glenn Adams gl...@skynav.com wrote: Further, a default behavior in the absence of such an injection might be defined simply to read data from the WS and stuff into the blob. Which kind of defeats the purpose because you wanted to read ranges, so not a whole resource has to be transferred, and you can already read binary data from websockets if you wish to do that, without having to invent another blob. A default behavior does not have to handle all uses cases. App specific code injection could handle this if the author wished it, provided a mechanism supported it.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard gl...@zewt.org wrote: Can we please stop saying lazy blob? It's a confused and confusing phrase. Blobs are lazy by design. On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams gl...@skynav.com wrote: So? Why should lazy blob be specific to HTTP specific semantics when an arbitrary URL is not specific to HTTP? XHR is no more specific to HTTP than it is to XML. It serves as the primary JavaScript API for performing generic network fetches. WebSockets has an entirely different API from blobs, and bringing them up is only derailing the thread. The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I will object to a LazyBlob solution that is tied solely to XHR, so deal with it now rather than later.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 2:35 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Aug 1, 2012 at 10:13 PM, Glenn Adams gl...@skynav.com wrote: The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I will object to a LazyBlob solution that is tied solely to XHR, so deal with it now rather than later. Then you better get onto specifying a resource/range transfer protocol on top of websockets alongside with web-server modules/extensions to be able to understand that protocol, because other than that there is no way that you'll get what you want. I don't think so. There is nothing about Blob that would require a data source to implement range access. Blob.slice() does not require the underlying source to provide range access. The source could be read in entirety and buffered by a Blob instance. If a reasonable WS enabled mechanism were defined for a Lazy Blob that permitted an application injected range access, then that could be used to perform actual range access. There is no need for WS/WSP to support those semantics directly. I don't particularly care if a default behavior for WS is provided that buffers the entire read stream. It's fine to mandate that an application defined function implement those semantics on a WS instance. My concern is that use of WS be recognized as a legitimate source for filling a lazy blob, and that an author should have an option to use WS, depending on app injected code as needed, instead of mandating XHR for this purpose. I'll leave the details of defining this to the proposers of lazy blob.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 9:35 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Aug 1, 2012 at 9:54 PM, Glenn Adams gl...@skynav.com wrote: I don't particularly care if a default behavior for WS is provided that buffers the entire read stream. Sorry, but that doesn't make sense. You don't access a message-based protocol (Web Sockets) using a character-based API (Blob). They're utterly different APIs. Have you read the Blob interface spec? To quote: This interface represents *immutable* raw data. It provides a method to slice http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice data objects between ranges of bytes into further chunks of raw data. The last time I checked, bytes are bytes, not characters. The fact that the interface provides access to those bytes via a particular string encoding is irrelevant. I'll leave the details of defining this to the proposers of lazy blob. You're free to come up with your own proposal, of course, and editors and vendors will choose among them (or come up with something else, or reject the idea entirely) as they always do, but others are not obligated to twist their proposals to your demands. Of course, implementers are free to ignore whatever they want, but last time I checked, the W3C was a consensus based standards organization which means agreement needs to be reached on what specs go out the door and what are in those specs. Since this is a W3C ML and not an implementers' forum, then I will continue to assume that the W3C process applies. There is a fixed obligation for editors and WG to address comments. They can't simply be rejected because they require work on the part of the editors or proposers.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 2:13 PM, Glenn Adams gl...@skynav.com wrote: On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard gl...@zewt.org wrote: Can we please stop saying lazy blob? It's a confused and confusing phrase. Blobs are lazy by design. On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams gl...@skynav.com wrote: So? Why should lazy blob be specific to HTTP specific semantics when an arbitrary URL is not specific to HTTP? XHR is no more specific to HTTP than it is to XML. It serves as the primary JavaScript API for performing generic network fetches. WebSockets has an entirely different API from blobs, and bringing them up is only derailing the thread. The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I will object to a LazyBlob solution that is tied solely to XHR, so deal with it now rather than later. Just to make it clear, I support the idea of defining a lazy blob mechanism. However, I am not satisfied that a solution that is tied solely to XHR is sufficient. I would like to see a mechanism that supports both XHR and WS [and others?]. Despite the repeated claims of Florian and GlennM that it doesn't make sense, etc., I think it does make sense and can be reasonably (and simply) defined to handle such use cases. If necessary I can volunteer a strawman to that end. However, I would prefer that DAR or other proposers take the time to consider this use case and factor it into their proposals.
Re: Lazy Blob
On Wed, Aug 1, 2012 at 10:44 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 1 Aug 2012, Glenn Adams wrote:
Of course, implementers are free to ignore whatever they want, but last
time I checked, the W3C was a consensus based standards organization
which means agreement needs to be reached on what specs go out the door
and what are in those specs.
Doesn't really matter what's in the specs going out the door if it's not
what's implemented...
I don't really care about the XHR side of this (happy to let Anne figure
that out), but since WebSockets was mentioned: what's the use case that
involves Web Socket? I don't really understand what problem we're trying
to solve here.
based on the pattern proposed by
partial interface BlobBuilder {
Blob getBlobFromURL (XMLHttpRequest xhr);
};
i would like to support two use cases:
(1) simple - single blob send, single blob response
(2) multiple - multiple instances of simple, i.e., send/response pairs
these could be handled with the following:
partial interface BlobBuilder {
// simple
Blob getBlobFromSource (WebSocket ws, Blob send);
// multiple
Blob getBlobFromSource (WebSocket ws, EventHandler sendHandler);
};
in the simple case, the creator of the lazy blob provides the initial send
blob, which is sent by the underlying lazy blob implementation upon a read
on the lazy blob, then the next (and only) response blob is returned as a
result from the read
in the multiple case, the creator of the lazy blob provides an event
handler to invoke to send a blob corresponding to a read on the lazy blob,
thus providing for multiple send/receive blob message pairs, with one lazy
blob for each pair
of course, the simple case could be folded into the multiple case, leaving
only one method to define:
partial interface BlobBuilder {
Blob getBlobFromSource (WebSocket ws, EventHandler sendHandler);
};
a use of this might be as follows:
var bb = new BlobBuilder();
var ws = new WebSocket(ws://example.com:/test);
var lb = [];
ws.onopen = function() {
lb.push ( bb.getBlobFromSource(ws, function() {
ws.send(getSendMessageAsBlob(1)); }) );
lb.push ( bb.getBlobFromSource(ws, function() {
ws.send(getSendMessageAsBlob(2)); }) );
lb.push ( bb.getBlobFromSource(ws, function() {
ws.send(getSendMessageAsBlob(3)); }) );
setTimeout(sendAndReceive);
}
function getSendMessageAsBlob(msgNum) {
return new Blob ( [ String(msgNum) ] );
}
function sendAndReceive() {
var numMsgs = 0;
var numBytes = 0;
// trigger read on queued lazy blobs
while ( lb.length 0 ) {
b = lb.shift();
// read on size triggers stored send 'promise'
numBytes += b.size;
numMsgs += 1;
}
alert('Received ' + numMsgs + ' messages, containing ' + numBytes + '
bytes.');
ws.close();
}
of course, this example make use of a particular message paradigm
(send/recv pairs); while this may capture only a subset of interchange
patterns, one could easily generalize the above to provide more flexibility;
Re: Lazy Blob
On Thu, Aug 2, 2012 at 1:04 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Aug 2012, Glenn Adams wrote: I don't really care about the XHR side of this (happy to let Anne figure that out), but since WebSockets was mentioned: what's the use case that involves Web Socket? I don't really understand what problem we're trying to solve here. i would like to support two use cases: (1) simple - single blob send, single blob response (2) multiple - multiple instances of simple, i.e., send/response pairs Sorry, I was vague. What I mean is what user-facing problem is it that we're trying to solve? see DAR's initial message in this thread; bringing WS into scope doesn't change the problem statement, it merely enlarges the solution space, or keeps it from being unnecessarily narrow
Re: Lazy Blob
On Thu, Aug 2, 2012 at 2:36 AM, Robin Berjon ro...@berjon.com wrote: On Aug 1, 2012, at 22:13 , Glenn Adams wrote: The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I will object to a LazyBlob solution that is tied solely to XHR, so deal with it now rather than later. Objections need to be built on something — just objecting for the fun of it does not carry some weight. Up to this point, you have provided no real world use case that requires the feature you propose and your sole justification for the whole subthread is that you don't like the idea. Are you saying I am objecting for the fun of it? Where did I say I don't like the idea? You'd best reread my messages. As far as I'm concerned, barring the introduction of better arguments the objection is dealt with hic et nunc. No it hasn't. If you want a real world use case it is this: my architectural constraints as an author for some particular usage requires that I use WS rather than XHR. I wish to have support for the construct being discussed with WS. How is that not a real world requirement?
Re: Lazy Blob
On Thu, Aug 2, 2012 at 9:51 AM, Florian Bösch pya...@gmail.com wrote: On Thu, Aug 2, 2012 at 5:45 PM, Glenn Adams gl...@skynav.com wrote: No it hasn't. If you want a real world use case it is this: my architectural constraints as an author for some particular usage requires that I use WS rather than XHR. I wish to have support for the construct being discussed with WS. How is that not a real world requirement? Your particular use-case of content/range aquisition over WS requires a particular implementation on the server in order to understand the WS application layer protocol. This particular implementation on the server of yours is not implemented by any other common hosting infrastructure based on any kind of existing standard. You should specify this particular protocol standard to be used on top of WS first before you can even discuss how your custom implementation of this protocol justifies enshrining it in a browser standard. All WS usage requires a particular (application specific) implementation on the server, does it not? Notwithstanding that fact, such usage will fall into certain messaging patterns. I happened to give an example of two possible message patterns and showed how the proposal under discussion could address those patterns. It is not necessary to marry my proposal to a specific sub-protocol on WS in order to provide useful functionality that can be exploited by applications that use those functions.
Re: Lazy Blob
On Thu, Aug 2, 2012 at 10:04 AM, Florian Bösch pya...@gmail.com wrote: On Thu, Aug 2, 2012 at 5:58 PM, Glenn Adams gl...@skynav.com wrote: All WS usage requires a particular (application specific) implementation on the server, does it not? Notwithstanding that fact, such usage will fall into certain messaging patterns. I happened to give an example of two possible message patterns and showed how the proposal under discussion could address those patterns. It is not necessary to marry my proposal to a specific sub-protocol on WS in order to provide useful functionality that can be exploited by applications that use those functions. If you wish to introduce a particular browser supported semantic for which a specific implementation on the server is required, then people should be able to consult a standard that tells them how they have to provide this implementation. Therefore it is quite necessary to marry your desire to extend remote blobs to WS to a protocol, otherwise you'll have a browser implemented protocol that nobody knows how to implement. I am not proposing a particular browser supported semantic for a specific implementation on the server. I have suggested, by way of example, two particular patterns be supported independently of any such implementation. I did not restrict the results to just those patterns in case someone wishes to generalize. That is little different from the proposed or implied XHR patterns being discussed.
Re: Lazy Blob
On Thu, Aug 2, 2012 at 11:01 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Aug 2012, Glenn Adams wrote: Sorry, I was vague. What I mean is what user-facing problem is it that we're trying to solve? see DAR's initial message in this thread; bringing WS into scope doesn't change the problem statement, it merely enlarges the solution space, or keeps it from being unnecessarily narrow Do you have a link to a specific message? I went through the archives and couldn't find any e-mails in this thread that came close to describing a use case for anything, let alone anything that would be related to persistent bi-directional full-duplex communication with a remote server. I was referring to [1]. [1] http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html While that message does not specifically refer to a full-duplex comm path, it states the general problem in terms of It is increasingly common that data may flow from a server to an in-browser page, that may then pass that data on to another in-browser page (typically running at a different origin). In a many cases, such data will be captured as Blobs. It goes on to describe a solution space oriented towards XHR as the comm path. It occurred to me that the same problem could apply to WS comm path patterns, which is why I suggested enlarging the solution space to include WS.
Re: Lazy Blob
On Thu, Aug 2, 2012 at 11:09 AM, Florian Bösch pya...@gmail.com wrote: On Thu, Aug 2, 2012 at 6:37 PM, Glenn Adams gl...@skynav.com wrote: I am not proposing a particular browser supported semantic for a specific implementation on the server. I have suggested, by way of example, two particular patterns be supported independently of any such implementation. I did not restrict the results to just those patterns in case someone wishes to generalize. That is little different from the proposed or implied XHR patterns being discussed. So I'll take a stab, the remote blob resource/range protocol over WS 1.0: 1) A websocket to a URL is opened by the browser, the path and query of the URL is interpreted to specify a resource. 2) During the lifetime of a websocket session onto a wsblob resource, the resource is guaranteed to be reflected unchanged to the session, it cannot be changed, appended or removed. 3) The client has to send these bytes handshake as a first message 4) The server has to respond with a handshakelength message to indicate that he understands this protocol and indicate the byte length of the resource. 5) after successful setup the client may request ranges from the server by sending this message: rangestartend, start and end have to be in range of the byte resource. 6) The server will respond to each range request in the form of rangestartendbytes in case that a range request is valid, the length of bytes has to be start - end. In case a range is not valid the server will respond with invalidstartend. These are the protocol field definitions: handshake := wsblob length := unsigned int 4 bytes start := unsigned int 4 bytes end := unsigned int 4 bytes bytes := string of bytes range := 0x01 invalid := 0x02 ok, that is fine, but I never suggested limiting the semantics of interchange to a resource/range protocol; as is clear, the above application specific protocol does in fact use the multiple pattern I described, i.e., each interchange consists of a pair of send-response messages, each of which can be encapsulated in a blob, and each response blob could be implemented as a remotable 'promise' encapsulating a send blob and its resultant response blob;
Re: Lazy Blob
On Thu, Aug 2, 2012 at 11:19 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Aug 2012, Glenn Adams wrote: I was referring to http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html While that message does not specifically refer to a full-duplex comm path, it states the general problem in terms of It is increasingly common that data may flow from a server to an in-browser page, that may then pass that data on to another in-browser page (typically running at a different origin). In a many cases, such data will be captured as Blobs. The above isn't a use case, it's a description of an architectural design, the first step towards the description of a solution. What I'm trying to understand is the underlying _problem_ that the technology is trying to solve. Something like I want to be able to sell plane tickets for people to go on holiday, say. Or I want to provide a service to users that lets them merge data from a medical drugs database and a patient database, without giving me their credentials to those databases. Or some such. I don't know exactly what the use case here would be, hence my questions. Are you asking for use cases for a remote/lazy blob in general? i.e., as would apply to the proposed XHR usage and any other underlying supported data source? or are you asking about high level use cases that are particular to a WS binding but not an XHR binding?
Re: Lazy Blob
On Thu, Aug 2, 2012 at 11:26 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Aug 2012, Glenn Adams wrote: Are you asking for use cases for a remote/lazy blob in general? i.e., as would apply to the proposed XHR usage and any other underlying supported data source? or are you asking about high level use cases that are particular to a WS binding but not an XHR binding? Both would be useful, but my primary concern is Web Sockets, since I edit that spec. Before I can consider proposals that affect Web Sockets, I need to know what use case it is we're trying to address. I will let Robin and Jungkee reply to the more general use case requirements. As far as WS is concerned, I don't see any impact of this thread on the WS API or WSP specs, its really simply an application of WS/WSP to remote/lazy blobs. Clearly, there are many high level use cases that involve a repetitive send/response message paradigm, which can certainly be implemented with XHR, but some application authors would prefer using WS for various efficiency reasons. My suggestion is essentially: if we are going to define a remote blob bound to an XHR source for a one-shot send-response, then perhaps we should define a remote blob bound to a WS source for multiple send-response pairs. For example, a symmetric presence protocol or IM protocol would typically fall into this usage category. Using remote blobs for either the send or response data (or both) would be useful for certain architectures and provide more deployment flexibility and perhaps greater efficiencies.
Re: Lazy Blob
On Mon, Aug 6, 2012 at 6:53 AM, Robin Berjon ro...@berjon.com wrote: So if you do have a use case, by all means please share it. If not, I maintain that you simply have no grounds for objection. I did share a couple of use cases in my response to Ian: On Thu, Aug 2, 2012 at 11:39 AM, Glenn Adams gl...@skynav.com wrote: On Thu, Aug 2, 2012 at 11:26 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Aug 2012, Glenn Adams wrote: Are you asking for use cases for a remote/lazy blob in general? i.e., as would apply to the proposed XHR usage and any other underlying supported data source? or are you asking about high level use cases that are particular to a WS binding but not an XHR binding? Both would be useful, but my primary concern is Web Sockets, since I edit that spec. Before I can consider proposals that affect Web Sockets, I need to know what use case it is we're trying to address. I will let Robin and Jungkee reply to the more general use case requirements. As far as WS is concerned, I don't see any impact of this thread on the WS API or WSP specs, its really simply an application of WS/WSP to remote/lazy blobs. Clearly, there are many high level use cases that involve a repetitive send/response message paradigm, which can certainly be implemented with XHR, but some application authors would prefer using WS for various efficiency reasons. My suggestion is essentially: if we are going to define a remote blob bound to an XHR source for a one-shot send-response, then perhaps we should define a remote blob bound to a WS source for multiple send-response pairs. For example, a symmetric presence protocol or IM protocol would typically fall into this usage category. Using remote blobs for either the send or response data (or both) would be useful for certain architectures and provide more deployment flexibility and perhaps greater efficiencies.
Re: Lazy Blob
On Mon, Aug 6, 2012 at 11:27 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 6 Aug 2012, Glenn Adams wrote: I did share a couple of use cases in my response to Ian: I will let Robin and Jungkee reply to the more general use case requirements. As far as WS is concerned, I don't see any impact of this thread on the WS API or WSP specs, its really simply an application of WS/WSP to remote/lazy blobs. Clearly, there are many high level use cases that involve a repetitive send/response message paradigm, which can certainly be implemented with XHR, but some application authors would prefer using WS for various efficiency reasons. My suggestion is essentially: if we are going to define a remote blob bound to an XHR source for a one-shot send-response, then perhaps we should define a remote blob bound to a WS source for multiple send-response pairs. For example, a symmetric presence protocol or IM protocol would typically fall into this usage category. Using remote blobs for either the send or response data (or both) would be useful for certain architectures and provide more deployment flexibility and perhaps greater efficiencies. Those are still not use cases, for the record. I tried explaining what a use case was here: http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0302.html http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0288.html I'll leave the translation of IM protocol to user facing use case as homework for the reader. It is trivial. My intent is to show a use case where one would use a persistent connection and a series of send/response messages that easily maps to WS. Instant Messaging is such a use case.
Re: Lazy Blob
On Mon, Aug 6, 2012 at 1:31 PM, Florian Bösch pya...@gmail.com wrote: On Mon, Aug 6, 2012 at 8:39 PM, Glenn Adams gl...@skynav.com wrote: I'll leave the translation of IM protocol to user facing use case as homework for the reader. It is trivial. My intent is to show a use case where one would use a persistent connection and a series of send/response messages that easily maps to WS. Instant Messaging is such a use case. What is it exactly that requires you to use a remote blob with type blob in the browser over a WS you cannot achieve with a WS and array buffers? The same reason that a remote blob would be useful with XHR.
Re: Lazy Blob
On Mon, Aug 6, 2012 at 2:06 PM, Florian Bösch pya...@gmail.com wrote: On Mon, Aug 6, 2012 at 9:33 PM, Glenn Adams gl...@skynav.com wrote: The same reason that a remote blob would be useful with XHR. Since you're steadfastly refusing to detail your use case, that'll just mean none to me. I feel I don't have any obligation to justify the use of WS any more than that necessary for XHR. It is simply short-sighted to define a remote blob only for XHR. If you can't see that, then let's not waste our time continuing this thread.
Re: Lazy Blob
On Tue, Aug 7, 2012 at 6:53 PM, Jungkee Song jungkee.s...@samsung.comwrote: - URLObject represents a resource that can be fetched, FileReader'd, createObjectURL'd, and cloned, but without any knowledge of the contents (no size attribute, no type attribute) and no slice() as URLObjects may not be seekable. - Blob extends URLObject, adding size, type, slice(), and the notion of representing an immutable piece of data (URLObject might return different data on different reads; Blob can not). +1 from me on this one. +1. I get a sense that this could possibly be a consensus position (or at least I'm going to claim that it is so as to get disagreement to manifest). Assuming it is, the next steps are: . Having agreed on a solution, do we agree on the problem? (i.e. would this get implemented?) . If so, we can bake this as a standalone delta spec but it would make more sense to me to make the changes directly to the relevant specs, namely FileAPI and XHR. I've copied Anne, Arun, and Jonas - any thought? In either case, I'm happy to provide the content. Having hammered out a consensus, I would like to contribute to providing the content. I would suggest using a different name than URLObject. I think that name will cause a lot of head scratching.
Re: Lazy Blob
On Tue, Aug 7, 2012 at 7:38 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams gl...@skynav.com wrote: I would suggest using a different name than URLObject. I think that name will cause a lot of head scratching. No disagreement there; that was just a placeholder. I'd suggest waiting for further input from Anne, Jonas and Arun (the editors of the specs in question) before spending much time coming up with a name, though. sure... i don't have a suggested replacement, but i know a bad name when i see one; i'll defer to the editors to come up with something reasonable
Re: [XHR] Setting the User-Agent header
On Wed, Sep 5, 2012 at 12:03 PM, Mark Nottingham m...@mnot.net wrote: The current draft of XHR2 doesn't allow clients to set the UA header. Presumably, by clients you mean client-side script, and not the [client] implementation of the UA. That's unfortunate, because part of the intent of the UA header is to identify the software making the request, for debugging / tracing purposes. Since client-side script, whether in a library referenced by a page or directly from the page, is not part of the UA, then it should not be able to modify the UA string. Given that lots of libraries generate XHR requests, it would be natural for them to identify themselves in UA, by appending a token to the browser's UA (the header is a list of product tokens). As it is, they have to use a separate header. And, IMO, should stay that way (use a separate header).
Re: [admin] Call for Editor for DOM4 REC track spec
It is worth noting that this is a critical path blocker for publishing HTML5 as a REC. On Fri, Sep 28, 2012 at 2:59 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi All, The current Editors of the DOM4 spec are not interested in moving that spec toward Recommendation (in the context of WebApps WG). Consequently, we need an Editor(s) to work on the DOM4 Recommendation track document. If you are interested in this Editor position and have relevant experience, please contact me offlist. -Thanks, ArtB [DOM4] http://dvcs.w3.org/hg/**domcore/raw-file/tip/Overview.**htmlhttp://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
Re: Call for Consensus: CORS to Candidate Recommendation
Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document. On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow art.bars...@nokia.comwrote: On 11/15/12 5:31 PM, ext Hill, Brad wrote: I have placed a draft for review at: http://www.w3.org/2011/**webappsec/cors-draft/http://www.w3.org/2011/webappsec/cors-draft/ And this is a Call for Consensus among the WebAppSec and WebApps WGs to take this particular text (with necessary additions to the Status of this Document section if approved) forward to Candidate Recommendation. I support this CfC although I am wondering about the CR exit criteria. Do you expect to re-use the CSP1.0 criteria: [[ The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. ]] My preference is what WebApps has used in other CRs because I think it is clearer that a single implementation is not required to pass every test but that at least two implementations must pass every test. F.ex.: http://www.w3.org/TR/2012/CR-**websockets-20120920/#crechttp://www.w3.org/TR/2012/CR-websockets-20120920/#crec -Thanks, AB
Re: Call for Consensus: CORS to Candidate Recommendation
Cox will file an FO (as a W3C member) if it is not fixed. On Fri, Nov 16, 2012 at 6:51 AM, Ms2ger ms2...@gmail.com wrote: I object to making such a change. On 11/16/2012 02:32 PM, Glenn Adams wrote: Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document. On Fri, Nov 16, 2012 at 6:17 AM, Arthur Barstow art.bars...@nokia.com wrote: On 11/15/12 5:31 PM, ext Hill, Brad wrote: I have placed a draft for review at: http://www.w3.org/2011/webappsec/cors-draft/http://www.w3.org/2011/**webappsec/cors-draft/ http://**www.w3.org/2011/webappsec/**cors-draft/http://www.w3.org/2011/webappsec/cors-draft/ And this is a Call for Consensus among the WebAppSec and WebApps WGs to take this particular text (with necessary additions to the Status of this Document section if approved) forward to Candidate Recommendation. I support this CfC although I am wondering about the CR exit criteria. Do you expect to re-use the CSP1.0 criteria: [[ The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. ]] My preference is what WebApps has used in other CRs because I think it is clearer that a single implementation is not required to pass every test but that at least two implementations must pass every test. F.ex.: http://www.w3.org/TR/2012/CR-websockets-20120920/#crechttp://www.w3.org/TR/2012/CR-**websockets-20120920/#crec ht**tp://www.w3.org/TR/2012/CR-**websockets-20120920/#crechttp://www.w3.org/TR/2012/CR-websockets-20120920/#crec -Thanks, AB
Re: [admin] Publication Rules [Was Re: Call for Consensus: CORS to Candidate Recommendation]
Unless I've missed it, I don't believe the #PubRules provides guidelines on what documents are referenced by a spec and whether the reference is normative or non-normative. If I'm wrong, please point out the policy or pubrules text that addresses this issue. Just to be clear, I don't object to including a non-normative reference to the WHATWG variant specification; however, if it is to be a normative reference, I'd like to insist it be the official W3C document that is referenced. On Fri, Nov 16, 2012 at 7:14 AM, Arthur Barstow art.bars...@nokia.comwrote: The W3C's process documents (e.g. #PubRules) define the policies for publications and this issue will be addressed if/when the CR is actually published. WebApps is simply a user of the publication policy. If you want to discuss W3C processes such as PubRules, please use some other list - and not any of WebApps' lists - such as public-w3cprocess #ProcCG. -Thanks, AB #PubRules http://www.w3.org/2005/07/**pubrules?uimode=filterhttp://www.w3.org/2005/07/pubrules?uimode=filter #ProcCG http://lists.w3.org/Archives/**Public/public-w3process/http://lists.w3.org/Archives/Public/public-w3process/ On 11/16/12 8:51 AM, ext Ms2ger wrote: I object to making such a change. On 11/16/2012 02:32 PM, Glenn Adams wrote: Before going to CR, I believe the [HTML] entry in the references section needs to be changed to reference an appropriate W3C specification. A present, it reference a non-W3C document.
Re: CfC: publish WD of XHR; deadline November 29
On Thu, Nov 22, 2012 at 6:27 AM, Anne van Kesteren ann...@annevk.nl wrote: If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Putting my name as former editor while all the text is either written by me or copied from me seems disingenuous. note that the label editor does not imply authorship; authors of W3C specs do not necessarily correspond to editors; in other cases in the W3C where editors change over the document's lifetime, all of the editors are often listed without marking which are current and which are not current; perhaps that would serve here, i.e., just include Anne in the list of editors
Re: CfC: publish WD of XHR; deadline November 29
On Fri, Nov 23, 2012 at 12:09 AM, Adam Barth w...@adambarth.com wrote: On Thu, Nov 22, 2012 at 9:16 AM, Ms2ger ms2...@gmail.com wrote: On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) as the basis http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html. Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I agree. The W3C should not be in the business of plagiarizing the work of others. Are you claiming that the W3C is in the business of plagiarizing? plagiarism. n. The practice of taking someone else's work or ideas and passing them off as one's own. The Status of this Document section should state clearly that this document is not an original work of authorship of the W3C. The SotD section need only refer to the working group that produced the document. Authorship is not noted or tracked in W3C documents. If Anne's work was submitted to and prepared in the context of the WebApps WG, then it is a product of the WG, and there is no obligation to refer to other, prior or variant versions. Referring to an earlier, draft version published outside of the W3C process does not serve any purpose nor is it required by the W3C Process. If there is a question on the status of the Copyright declaration of the material or its origin, then that should be taken up by the W3C Pubs team. G.
