[widgets] features: default value for required
Hi all, The algorithm for processing the 'required' attribute is unclear. It says: If a required attribute is used, then let required-feature be the result of applying the rule for getting a single attribute value to the required attribute. If required-feature is not a valid boolean value, then let the value of required-feature be the value 'true'. I think it misses the case when the required attribute is not used. According to the 'Authoring Guideline', it should say: If a required attribute is used, then let required-feature be the result of applying the rule for getting a single attribute value to the required attribute. *If the required attribute is not used or *if required-feature is not a valid boolean value, then let the value of required-feature be the value 'true'. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
[widgets] feature: inconsistent behavior ?
Hi, The test df.wgt contains a feature without name. In this case, the feature element is ignored and the widget remains valid. The test d4.wgt contains an invalid feature name. In this case, the widget should be considered as invalid. I don't understand that. I understand the rationale that if a feature is required, the UA shall not process the widget. Whether it does or not understand the feature, it doesn't matter. Is it because you foresee evolution in the syntax of feature names, which wouldn't be IRI ? If not, I suggest to make this test pass and ignore the feature element. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets
[widgets] duplicated feature elements ?
Hi all, There is a test in the test suite for duplicated param element with the same name but different value (v9.wgt). But I did not find, a similar test for duplicated feature elements with the same name. Is this allowed or not ? The algorithm in Step 7 does not say. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Dec 7, 2009, at 7:46 PM, Barstow Art (Nokia-CIC/Boston) wrote: This is a Call for Consensus (CfC) to publish a Last Call Working Draft of the following specs: 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web SQL Database http://dev.w3.org/html5/webdatabase/ 3. Web Sockets API http://dev.w3.org/html5/websockets/ 4. Web Storage http://dev.w3.org/html5/webstorage/ 5. Web Workers http://dev.w3.org/html5/workers/ Based on the comments for this CfC, we have unanimous support to publish LCWDs of: Server-Sent Events, Web Storage and Web Workers. Hixie - please prepare these 3 specs for a 17 December publication and a LC comment period ending 30 June 2010. Several members of the group (Nikunj[1], Charles[2], Arun[3], Art[4], Adrian[5]) raised concerns about Web SQL Database where the primary concerns raised are the normative User agents must implement the SQL dialect supported by Sqlite 3.6.19 requirement and a commitment for a second implementation of this requirement. Adrian raised some concerns [5] about Web Sockets API and these should be discussed on the list. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 1262.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 1264.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 1265.html [4] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 1311.html [5] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 1335.html
RE: Widget specification - liquid height support
Robmin, The specification says that in some view modes the widget user agent will use the width and high specified in the config.xml file. What would happened in such a view mode if they were not mentioned? אייל סלע | מנהל פרויקטים, הועדה הטכנולוגית ומשרד ה-W3C הישראלי | איגוד האינטרנט הישראלי | 03-9700910 | www.isoc.org.il | www.w3c.org.il Eyal Sela | Project Manager, Technology Committee the Israeli W3C office | Israel Internet Association (ISOC-IL) | Tel: +972-3-9700910 | www.isoc.org.il | www.w3c.org.il -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Friday, December 11, 2009 5:43 PM To: Amit Kasher Cc: public-webapps@w3.org; 'Eyal Sela'; Amit Monbaz Subject: Re: Widget specification - liquid height support Hi Amit, On Dec 10, 2009, at 15:54 , Amit Kasher wrote: I couldn’t find any mentioning to the “liquidness” of the new HTML element “widget”. What happens if one does not configure any height or width to it? In terms of width, I assume it behaves like a div and takes the entire container width, but what happens with height? Does it behave like a div that changes its height according to its content, or does it behave like an iframe that doesn’t? I think you have misunderstood the purpose of the widget element. It is not meant to be used in HTML documents, or for that matter to ever be rendered. It simply is a container for the configuration of widgets, as part of the config.xml file that widget packages contain. -- Robin Berjon - http://berjon.com/
Widget packaging conformance
The Widgets 1.0: Packaging and Configuration working draft says that There is only one class of product that can claim conformance to this specification: a user agent.. The standard specify features of Widgets, not only of widget user agents, then why can't a Widget itself be claimed to conform to the it? אייל סלע | מנהל פרויקטים, הועדה הטכנולוגית | איגוד האינטרנט הישראלי | 03-9700910 | 054-4458271 | http://www.isoc.org.il www.isoc.org.il Eyal Sela | Project Manager, Technology Committee | Israel Internet Association (ISOC-IL) | Tel: +972-3-9700910 | http://www.isoc.org.il www.isoc.org.il
[widgets] Draft Agenda for 17 December 2009 voice conference
Below is the draft agenda for the 17 December Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/12/10-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 60 minutes max Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public Agenda: 1. Review and tweak agenda 2. Announcements a. Next call is 7 January 2010 3. Digital Signature spec http://dev.w3.org/2006/waf/widgets-digsig/ a. Test suite status http://www.w3.org/2008/webapps/wiki/ WidgetTesting#Widgets_1.0:_Digital_Signature_spec b. Implementation status http://www.w3.org/2008/webapps/wiki/WidgetImplementation 4. URI Scheme spec http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ a. Status of LC comments: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- uri-20091008/doc/ b. Scheme registration 5. View Modes Media Features spec: http://dev.w3.org/2006/waf/widgets-vmmf/ a. Status of VF's doc: http://lab.vodafone.com/w3c/vmmf-20091201.html 6. Updates spec: http://dev.w3.org/2006/waf/widgets-updates/ a. CfC to publish new WD 7. AOB
Regrets
Hi, I will not be able to attend the call tomorrow. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
[xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)
(Moving this thread over to the WebApps WG.) On Sat, 05 Dec 2009 00:06:35 +0100, Alexey Proskuryakov a...@webkit.org wrote: On 04.12.2009, at 14:30, Jonas Sicking wrote: However for the events that are fired as a result of network activity, I see no reason to fire these events asynchronously from that code. Sounds like we're in complete agreement here. I've missed the change from sync to async dispatch when it was made in XHR specs (both v1 and v2), and I think that it should be reverted. That sounds right. I initially misunderstood the way the task queue would work together with XMLHttpRequest. It seemed sort of natural that events for asynchronous requests would be queued as tasks, but I see that if the network event itself is queued we can remove that. So to be clear, under step seven of the send() method in http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-send-method nothing would change. We still want to queue tasks for things that happen on the network so that the same-origin request event rules run asynchronously as it were. However, everything that follows from that should no longer queue a task, right? I.e. once the initial task queued as result of network activity is run everything should be done synchronously. Later on in the thread on the WHATWG you and Ian allude to difficulties with the XMLHttpRequest specification with respect to race conditions if we rearrange this. Could you perhaps give an example as I am not sure what would be an issue if I make the above changes. -- Anne van Kesteren http://annevankesteren.nl/
Re: XMLHttpRequest Comments from W3C Forms WG
On Wed, 25 Nov 2009 21:46:59 +0100, Klotz, Leigh leigh.kl...@xerox.com wrote: This comment on XMLHttpRequest [1] is from the Forms WG. A standalone W3C Recommendation-track document is welcome, particularly because of the statement in [2] The goal of this specification is to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code. This goal was widely quoted in web discussion on the working drafts, and is no doubt an attractive feature of a standalone specification document. Note that we changed this goal slightly because documenting the mimimum set of interoperable features did not work very well once you went beyond a certain level of detail. The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. It appears that the current draft, howevever, has a wide dependence on HTML5: [3] This specification already depends on HTML 5 for other reasons so there is not much additional overhead because of this. This is not new, actually, but alas. That dependence runs counter to the goals of allowing Web developers to use the features without platform-specific code. Why would that be? HTML5 is not platform-specific. While it may be useful for the HTML5 specifications to include XMLHTTPRequest and make enhancements to it, the dependency should be from HTML5 on XMLHttpRequest, and not vice versa. Making XMLHttpRequest depend on HTML5 causes problems with non-HTML5 implementations of the feature. HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, etc. In summary, we feel that the dependencies between HTML5 and XMLHttpRequest are in the wrong direction. We ask that the dependency on HTML5 be eliminated, and that the XMLHttpRequest Working Draft be changed to specify minimum requirements for integration in the areas for which it depends on HTML5. The HTML5 document itself can surely satisfy these requirements. I do not think it makes sense that a user agent that implements e.g. HTML5 and SVG would have two implementations of XMLHttpRequest. HTML5 simply defines some core underlying concepts and these will be the same everywhere. There are indeed things that can differ depending on the context and those have been abstracted out, as you found. Mostly to facilitate Web Workers, but I can imagine these hooks might be used elsewhere too. [1] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119 [2] http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ [3] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#dependencies (I corrected the numbering here.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Comments on Last Call Working Draft of XHR
On Thu, 26 Nov 2009 18:25:57 +0100, Richard Ishida ish...@w3.org wrote: Hopefully you'll get a formal response from the i18n WG shortly. In the meantime, I have only a couple of personal editorial suggestions: I have not seen a response from the i18n WG. [1] 2.2 terminology It would help a lot to link each of the terms defined in html5 to the appropriate location in the html5 spec, if possible. We have this situation in several specifications at the moment. I'm not sure what the correct solution will be here so I rather wait with implementing something until we agree on something that will work everywhere. I agree it is not ideal, but having to update all the terminology links all the time is not great either. [2] same section I was confused by the term document's character encoding. I suspect this ought to be character encoding (of the document), where the parenthesised text is non-bold. The problem was that I thought document's character encoding was a single term, like URL character encoding, and was something different than character encoding (in the same way that document character set is different from character set). It is actually a single term, defined by HTML5. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Small text correction.
On Tue, 15 Dec 2009 08:06:35 +0100, Huub Schaeks h...@h-schaeks.speedlinq.nl wrote: The third sentence in section 4.1 reads: When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate for that context. I think the word is, is missing in the first part of it: When the XMLHttpRequest object is used in other contexts their values will have to be defined as appropriate for that context. Fixed, thanks! -- Anne van Kesteren http://annevankesteren.nl/
[xhr] Blocked headers with underscore rather than hyphen (was: Re: call for reviewers: XMLHttpRequest Last Call)
On Wed, 09 Dec 2009 11:33:25 +0100, s...@rckc.at s...@rckc.at wrote: http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html -- Eduardo It seems it is not considered an issue for same-origin requests per that page and cross-origin requests are only dealt with in XMLHttpRequest Level 2 which requires strict per-header opt-in. Have you talked with implementors about this? -- Anne van Kesteren http://annevankesteren.nl/
Re: [xhr] Blocked headers with underscore rather than hyphen (was: Re: call for reviewers: XMLHttpRequest Last Call)
Hmm well, the only difference is that this attacks would now work same-site.. I mean.. XHR is restricting that user-agent, and other headers shouldn't be sent, supposedly to protect the JS code to send wrong headers to the server, but if the restriction can be fooled using a _, isn't the restriction useless now? It's not an issue that affects all server, but it does affect a very famous one.. Anyway, it's not a very serious issue.. I just wanted to know if it was going to be considered. -- Eduardo http://www.sirdarckcat.net/ Sent from Hangzhou, Zhejiang, China On Wed, Dec 16, 2009 at 11:17 PM, Anne van Kesteren ann...@opera.comwrote: On Wed, 09 Dec 2009 11:33:25 +0100, s...@rckc.at s...@rckc.at wrote: http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html -- Eduardo It seems it is not considered an issue for same-origin requests per that page and cross-origin requests are only dealt with in XMLHttpRequest Level 2 which requires strict per-header opt-in. Have you talked with implementors about this? -- Anne van Kesteren http://annevankesteren.nl/
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Wed, 16 Dec 2009, Arthur Barstow wrote: Several members of the group (Nikunj[1], Charles[2], Arun[3], Art[4], Adrian[5]) raised concerns about Web SQL Database where the primary concerns raised are the normative User agents must implement the SQL dialect supported by Sqlite 3.6.19 requirement and a commitment for a second implementation of this requirement. The second concern seems more appropriate as a reason not to exit CR than as a reason to not enter LC. Nothing in the process precludes developing drafts up to CR without an implementation commitment. Is there any way to address the first concern? In the meantime, could we publish this draft as a regular WD, so that the /TR/ version is in sync with the latest draft? Adrian raised some concerns [5] about Web Sockets API and these should be discussed on the list. Will do. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)
On Wed, 16 Dec 2009, Anne van Kesteren wrote: (Moving this thread over to the WebApps WG.) On Sat, 05 Dec 2009 00:06:35 +0100, Alexey Proskuryakov a...@webkit.org wrote: On 04.12.2009, at 14:30, Jonas Sicking wrote: However for the events that are fired as a result of network activity, I see no reason to fire these events asynchronously from that code. Sounds like we're in complete agreement here. I've missed the change from sync to async dispatch when it was made in XHR specs (both v1 and v2), and I think that it should be reverted. That sounds right. I initially misunderstood the way the task queue would work together with XMLHttpRequest. It seemed sort of natural that events for asynchronous requests would be queued as tasks, but I see that if the network event itself is queued we can remove that. So to be clear, under step seven of the send() method in http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-send-method nothing would change. We still want to queue tasks for things that happen on the network so that the same-origin request event rules run asynchronously as it were. However, everything that follows from that should no longer queue a task, right? I.e. once the initial task queued as result of network activity is run everything should be done synchronously. Sounds right. Later on in the thread on the WHATWG you and Ian allude to difficulties with the XMLHttpRequest specification with respect to race conditions if we rearrange this. Could you perhaps give an example as I am not sure what would be an issue if I make the above changes. The race condition could occur under the following circumstances: * A setTimeout task is queued. * The setTimeout task starts running, but it takes several seconds. While it is running: * A task is queued under step 7, because all the HTTP headers have been received. * Another task is queued under step 7, because the first byte of the response entity body has been received. * The setTimeout task finishes. * The first same-origin request event rules task runs. The event is fired. The event calls abort(). The relevant algorithm runs. * The first task finishes. * The second same-origin request event rules task runs. The object's state is updated and the event is fired, even though the object has already had abort() called. This is the race condition. On another note, while reading the spec I noticed that no task is queued to updated responseText. Does that mean that if I check it continually in a tight loop within a task, I can see it change? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: The most basic File API use case
Hi Jonas,
On Dec 10, 2009, at 19:42 , Jonas Sicking wrote:
On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon ro...@berjon.com wrote:
[Constructor(DOMString mediaType, DOMString fileName)]
interface FileWriter {
// saving operations
void save (DOMString content, optional DOMString encoding, optional
DOMString endings);
void save (Blob data);
Hmm.. I'm not entirely convinced that it's worth having the first of
these two methods. You're already up to two optional arguments, and
more might be needed (such as if to include a BOM or not). It might be
simpler to simply require people to create Blobs and then save that
Blob.
I could live with other options but there are things that are quite specific to
writing text, amongst them at the very least using the same encoding throughout
(which is clumsy if you have to append several times to a blob and specify it
every time. I thought of having a TextBlob that could take encoding, line
endings, BOM, etc. as parameters to its constructor and then passing that to
save() but I'm not entirely sure that what we get from the change is really
valuable.
How about:
void save (DOMString content, TextOptions options);
where the second argument would be an object literal that could capture all of
this?
Another option would be:
Blob textToBlob (DOMString content, TextOptions options);
possibly on another interface but again I'm not sure what that gains us. Do we
have use cases for textual blobs being used elsewhere? If yes, then I'm
thinking:
interface TextBlobBuilder {
attribute DOMString content;
attribute DOMString encoding;
attribute DOMString endings;
attribute boolean BOM;
Blob generateBlob ();
};
Thoughts?
// abort the save
void abort();
// state codes
const unsigned short INITIAL = 0;
const unsigned short WRITING = 1;
const unsigned short DONE= 2;
readonly attribute unsigned short readyState;
// error, same as FileReader but with some additions
readonly attribute FileError error;
// event handler attributes
attribute Function onloadstart;
attribute Function onprogress;
attribute Function onload;
attribute Function onabort;
attribute Function onerror;
attribute Function onloadend;
I think most of this is overkill. What is the use case for progress
events here? I.e. why does the page need to know how much data has
been written? And why would you want to abort writing the file?
Well, if there are use cases for reading, the same apply for writing. If you
build a large file (e.g. for graphics editing) and save it to a slow storage
(e.g. network drive, SIM) then it could take a very measurable amount of time
(this happens in Photoshop even on powerful computers), and if it does you
probably want to inform the user and to provide her with a way to give up.
This is essentially a mirror of FileReader; I think it makes sense and not just
for consistency.
[Constructor]
interface WritableBlob : Blob {
void put (Blob blob);
void put (octet val);
void put (DOMString string, optional DOMString encoding);
};
I'd prefer the concept of a Blob factory than mutable blobs. With
mutable blobs we (or at least the implementation) has to worry about
things like what if the blob mutates in the middle of being read or
written. For example if you do:
b = new WriteableBlob();
worker.postMessage(b);
b.put(14);
Heh, so basically you don't think that it could take long enough that progress
events may be needed but you do fear that it may be slow enough that people
could change the objects as they're being processed? :)
You make a good argument though, I'll re-switch the approach to use a builder.
Further, I would probably rename 'put' to 'append' to make it more
clear that it doesn't overwrite data appended so far.
My initial idea was that put() could also write in other locations if we had
seek(), but no one else seems to think this might be useful so I'm happy to
switch to append().
I'll produce an updated draft soon.
--
Robin Berjon - http://berjon.com/
FW: [widgets] comments re View Modes Interface spec
Thanks Marcin for your response, my comments are embedded below, marked with [YA] -Original Message- From: ext Marcin Hanclik [mailto:marcin.hanc...@access-company.com] Sent: Monday, December 07, 2009 9:01 AM To: Barstow Art (Nokia-CIC/Boston); public-webapps Cc: Aharon Yael (Nokia-D/Boston) Subject: RE: [widgets] comments re View Modes Interface spec Hi Yael, Art, Thanks for your comments. Below are my comments and refining questions. Please let me know what you think. Below are some comments from Yael re the View Modes Interface spec: http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html -Art Barstow = Section 3.1: Interface Media: 1. Interface Media is also defined in CSSOM (4.1), and the definition is not consistent. I cannot find the definition of the interface Media in CSSOM in section 4.1. Did you mean 4.4 interface MediaList (also in DOM2CSS) and mediaText attribute? mediaText is the same as Media, but it has just different syntax. Therefore I would opt for removal of the Media interface. I think it should be defined in one spec, and the other spec should refer to that. Agreed. Alignment will require discussion with Anne. [YA] Sorry, I was referring to http://www.w3.org/TR/cssom-view/ , and it already defines the Media interface. 2. onTypeChanged attribute is defined to be an event. Usually, onXXchanged attributes are defined as event listeners, I think this is a mistake. Agreed. I am thinking about removal of this attribute. The events are dispatched on the Document, therefore event handler/listener seems not needed. Any thoughts? [YA] Removing this attribute seems like the best option to me. = Section 3.2: 1. I do not understand the use-case for changing media type. According to CSS2-Media (7.3), e.g., the act of printing a document would add a second canvas, and would not change the media type of the existing canvas. This depends on UA. E.g. as for printing you could switch the media type, print and switch it back. This use case seems to be intentionally specified as may to give the UAs some freedom. Changing media type within a media group (CSS2-Media 7.3.1) resembles e.g. changing resolution and color-depth. For example, you could switch between print, projection, screen, tty, tv within visual media group. [YA] My understanding of http://www.w3.org/TR/CSS2/media.html , Media types are mutually exclusive in the sense that a user agent can only support one media type when rendering a document. However, user agents may use different media types on different canvases. For example, a document may (simultaneously) be shown in 'screen' mode on one canvas and 'print' mode on another canvas. , it seems to me that you don't change the Media type, but add a new canvas. = Section 3.4: 1. The media feature Resolution is defined in CSS3-Media-Queries (4.11) as density of the pixels, e.g. DPI. It is very confusing to reuse the same name (resolution) for something completely different. Agreed. There is a related mail thread [1] in which this topic is discussed. Nevertheless I think that ResolutionChangeEvent would be helpful to notify about the changed resolution (in its original sense). [YA] I still don't understand the use case for changing the resolution of a device. BTW: Actually also the term media type has different meanings (PC vs. CSS), but in this case I think of saying CSS media type. 2. Would ResizeEvent be sufficient instead of adding the new event ResolutionChangedEvent ? What about SizeChangedEvent? Just for naming consistency. [YA] I was actually thinking about resize event as defined in http://www.w3.org/TR/DOM-Level-2-Events/events.html . Thanks, Yael
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Dec 16, 2009, at 11:54 AM, ext Ian Hickson wrote: On Wed, 16 Dec 2009, Arthur Barstow wrote: Several members of the group (Nikunj[1], Charles[2], Arun[3], Art[4], Adrian[5]) raised concerns about Web SQL Database where the primary concerns raised are the normative User agents must implement the SQL dialect supported by Sqlite 3.6.19 requirement and a commitment for a second implementation of this requirement. Is there any way to address the first concern? As some have noted previously, we would need a normative specification of the SQL dialect. Another option is to move the doc to the WG Note track. In the meantime, could we publish this draft as a regular WD, so that the /TR/ version is in sync with the latest draft? Yes. The requirements for publishing a plain (non-Last Call) WD are quite low and do not require consensus. I'll submit a publication request today. -Art Barstow
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Wed, 16 Dec 2009, Arthur Barstow wrote: On Dec 16, 2009, at 11:54 AM, ext Ian Hickson wrote: On Wed, 16 Dec 2009, Arthur Barstow wrote: Several members of the group (Nikunj[1], Charles[2], Arun[3], Art[4], Adrian[5]) raised concerns about Web SQL Database where the primary concerns raised are the normative User agents must implement the SQL dialect supported by Sqlite 3.6.19 requirement and a commitment for a second implementation of this requirement. Is there any way to address the first concern? As some have noted previously, we would need a normative specification of the SQL dialect. Another option is to move the doc to the WG Note track. Ok. Then I propose that we leave it at WD for now, since I do not intend to write a definition of the SQL dialect unless someone intends to implement this without using Sqlite. If anyone ever does want to implement Web SQL Database without Sqlite, please let me know and I'll spec out the SQL dialect. In the meantime, could we publish this draft as a regular WD, so that the /TR/ version is in sync with the latest draft? Yes. The requirements for publishing a plain (non-Last Call) WD are quite low and do not require consensus. I'll submit a publication request today. Thanks. What's the deadline by which we have to have submitted a request? If there's time, I'd like to address Adrian's feedback on the Web Sockets API and then either publish it as LC (if Adrian agrees) or at least WD. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)
On Wed, Dec 16, 2009 at 9:37 AM, Ian Hickson i...@hixie.ch wrote: On another note, while reading the spec I noticed that no task is queued to updated responseText. Does that mean that if I check it continually in a tight loop within a task, I can see it change? I think the spec should say that when data arrives from the network, a task should be queued. When this task runs, it should perform the following steps synchronously: 1. Update .responseText 2. If readystate is not yet 3, set it to 3 and fire readystatechange 3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired within the past 50ms / Jonas
RE: XMLHttpRequest Comments from W3C Forms WG
Anne, Thank you for your corrections and updates. I'd like to suggest that the main issue is dependency of the XHR document on concepts where HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, Etc. If this is indeed the case, and the dependency cannot be abstracted out, then XHR must well and truly be considered a part of HTML5. However, since you site SVG as another user of XHR, then it seems that it's still a goal to have XHR not require HTML5. Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. Thank you, Leigh. -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Wednesday, December 16, 2009 6:54 AM To: Klotz, Leigh; WebApps WG Cc: Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On Wed, 25 Nov 2009 21:46:59 +0100, Klotz, Leigh leigh.kl...@xerox.com wrote: This comment on XMLHttpRequest [1] is from the Forms WG. A standalone W3C Recommendation-track document is welcome, particularly because of the statement in [2] The goal of this specification is to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code. This goal was widely quoted in web discussion on the working drafts, and is no doubt an attractive feature of a standalone specification document. Note that we changed this goal slightly because documenting the mimimum set of interoperable features did not work very well once you went beyond a certain level of detail. The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. It appears that the current draft, howevever, has a wide dependence on HTML5: [3] This specification already depends on HTML 5 for other reasons so there is not much additional overhead because of this. This is not new, actually, but alas. That dependence runs counter to the goals of allowing Web developers to use the features without platform-specific code. Why would that be? HTML5 is not platform-specific. While it may be useful for the HTML5 specifications to include XMLHTTPRequest and make enhancements to it, the dependency should be from HTML5 on XMLHttpRequest, and not vice versa. Making XMLHttpRequest depend on HTML5 causes problems with non-HTML5 implementations of the feature. HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, etc. In summary, we feel that the dependencies between HTML5 and XMLHttpRequest are in the wrong direction. We ask that the dependency on HTML5 be eliminated, and that the XMLHttpRequest Working Draft be changed to specify minimum requirements for integration in the areas for which it depends on HTML5. The HTML5 document itself can surely satisfy these requirements. I do not think it makes sense that a user agent that implements e.g. HTML5 and SVG would have two implementations of XMLHttpRequest. HTML5 simply defines some core underlying concepts and these will be the same everywhere. There are indeed things that can differ depending on the context and those have been abstracted out, as you found. Mostly to facilitate Web Workers, but I can imagine these hooks might be used elsewhere too. [1] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119 [2] http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ [3] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#dependencies (I corrected the numbering here.) -- Anne van Kesteren http://annevankesteren.nl/
RE: XMLHttpRequest Comments from W3C Forms WG
I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. Happy Holidays, Ian, Anne, and all. Leigh. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Wednesday, December 16, 2009 11:54 AM To: Klotz, Leigh Cc: Anne van Kesteren; WebApps WG; Forms WG Subject: RE: XMLHttpRequest Comments from W3C Forms WG On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: XMLHttpRequest Comments from W3C Forms WG
If this is the case, it shouldn't be too much work then to take out the parts that don't need to be implemented and put them into a separate, rec-track document entitled roughly XHR for HTML5. Leigh. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, December 16, 2009 12:04 PM To: Klotz, Leigh Cc: Ian Hickson; Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG Note that just referring to a few specific concepts defined in HTML5 does not force anyone to implement the rest of HTML5. As things stand right now it's quite possible to implement XMLHttpRequest according to spec, without implementing almost anything in the HTML5 spec. Put it another way, abstracting out these concepts from the HTML5 spec would on a technical level not change what anyone would need to implement. / Jonas On Wed, Dec 16, 2009 at 11:56 AM, Klotz, Leigh leigh.kl...@xerox.com wrote: I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. Happy Holidays, Ian, Anne, and all. Leigh. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Wednesday, December 16, 2009 11:54 AM To: Klotz, Leigh Cc: Anne van Kesteren; WebApps WG; Forms WG Subject: RE: XMLHttpRequest Comments from W3C Forms WG On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Dec 16, 2009, at 2:46 PM, ext Ian Hickson wrote: What's the deadline by which we have to have submitted a request? If there's time, I'd like to address Adrian's feedback on the Web Sockets API and then either publish it as LC (if Adrian agrees) or at least WD. The deadline is 18 December, 12pm ET and a few related e-mails this week indicated that earlier is strongly recommended. -Art Barstow
RE: XMLHttpRequest Comments from W3C Forms WG
On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. FWIW, there is a general agreement that this would be an ideal thing to do; it really does boil down to lack of manpower. We did try at one point to do it, but the effort floundered. If you know of anyone who would be knowedgable enough to edit such a draft, and who would have the time to do it, please do let us know. I would be happy to help someone get started on this. I estimated in 2008 that someone with the suitable skills would face the following workload: | - 4 months at 40h/week extracting existing text from HTML5 | - 12 months at 40h/week reverse-engineering and specifying | - 12 months at 40h/week responding to feedback | - 24 months at 5h/week responding to feedback -- http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html (#10) Some of that is reduced now, since some progress has been made on the relevant material, but it'd still probably be in the same ballpark. Happy Holidays, Ian, Anne, and all. Likewise. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Wed, 16 Dec 2009 20:46:03 +0100, Ian Hickson i...@hixie.ch wrote: What's the deadline by which we have to have submitted a request? If there's time, I'd like to address Adrian's feedback on the Web Sockets API and then either publish it as LC (if Adrian agrees) or at least WD. I think it makes more sense to publish as a working draft right now. The reality is that wider review that wasn't actually done earlier is often triggered by people holding something up, so assuming that your approach to addressing those comments in one day would result in a draft the entire group thinks is ready if they actually review it carefully seems optimistic at best. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
RE: XMLHttpRequest Comments from W3C Forms WG
Thank you. It does seem like a daunting amount of effort, and I hope it doesn't cause the XHR draft to be derailed. Things that are impossible just take longer ;-) Leigh. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Wednesday, December 16, 2009 12:13 PM To: Klotz, Leigh Cc: Anne van Kesteren; WebApps WG; Forms WG Subject: RE: XMLHttpRequest Comments from W3C Forms WG On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. FWIW, there is a general agreement that this would be an ideal thing to do; it really does boil down to lack of manpower. We did try at one point to do it, but the effort floundered. If you know of anyone who would be knowedgable enough to edit such a draft, and who would have the time to do it, please do let us know. I would be happy to help someone get started on this. I estimated in 2008 that someone with the suitable skills would face the following workload: | - 4 months at 40h/week extracting existing text from HTML5 | - 12 months at 40h/week reverse-engineering and specifying | - 12 months at 40h/week responding to feedback | - 24 months at 5h/week responding to feedback -- http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html (#10) Some of that is reduced now, since some progress has been made on the relevant material, but it'd still probably be in the same ballpark. Happy Holidays, Ian, Anne, and all. Likewise. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [DataCache] Some Corrections
On Dec 4, 2009, at 9:41 AM, Joseph Pecoraro wrote: - 4.1.1 Examples http://dev.w3.org/2006/webapi/DataCache/#examples Last code example is improperly indented. Fixed - 4.2.1 Opening a Cache has a typo in Step 3.2 http://dev.w3.org/2006/webapi/DataCache/#opening-cache If data cache group does not exist, the perform the following substeps: should be: If data cache group does not exist, then perform the following substeps: also, maybe substeps should be sub-steps ? Fixed - 4.2.1. Opening a cache is missing step? http://dev.w3.org/2006/webapi/DataCache/#opening-cache Both arms of step 3 don't specify the `data cache` to use if the `data cache group` is defined / exists. For example, the first arm of step 3 is: [[ 1. If there is an unsecure data cache group for origin origin, let data cache group be that existing data cache group. 2. If data cache group does not exist, the perform the following substeps: 1. Create a new data cache, called data cache, in a new unsecure data cache group for origin origin called data cache group. 2. Set the completeness flag of data cache to incomplete. 3. Set the update status of data cache group to idle. ]] Sub-step 2 is the only step that creates a `data cache`. Thus, if a data cache group exists, the current text does not specify what the `data cache` should be. I suggest this be clarified, in both arms, like so (adding a new step #2): 1. If there is an unsecure data cache group for origin origin, let data cache group be that existing data cache group. 2. If data cache group exists let data cache be the effective data cache of data cache group. 3. If data cache group does not exist, then perform the following substeps: 1. Create a new data cache, called data cache, in a new unsecure data cache group for origin origin called data cache group. 2. Set the completeness flag of data cache to incomplete. 3. Set the update status of data cache group to idle. Thanks for catching this. I have fixed it. Where effective data cache can be a link to: http://dev.w3.org/2006/webapi/DataCache/#effective-data-cache On the same note, effective cache [1 time] and effective data cache [9 times] are both used throughout the draft to mean the same thing. I would suggest that effective cache be updated to effective data cache for consistency. Fixed - 4.2.2.1. Starting a transaction - Rules should be switched. http://dev.w3.org/2006/webapi/DataCache/#starting-a-transaction first arm: (these should be swapped) 3.3 - Mark transaction as off-line. 3.4 - Create a new cache transaction called transaction and set data cache to be its data cache. second arm: (these should be swapped) 3.4 - Mark transaction as not off-line. 3.5 - Create a new cache transaction called transaction and set data cache to be its data cache. I don't agree. The transaction is off-line, if the off-line flag passed to these steps is set. - 4.2.5 Asynchronous Data Cache API typo three times: http://dev.w3.org/2006/webapi/DataCache/#cache-status This DataCache object's cache host is aassociated with a... s/aassociated/associated/; // 3 times Fixed Cheers, Joseph Pecoraro Nikunj http://o-micron.blogspot.com
Re: [DataCache] Some Corrections
On Dec 7, 2009, at 12:01 PM, Joseph Pecoraro wrote:
Some more DataCache API Corrections:
- 4.1.1. Examples
http://dev.w3.org/2006/webapi/DataCache/#examples
No such thing as finish() used in the first example. Perhaps this
should be commit()?
[[
cache.transaction(function(txn) {
txn.capture(uri);
txn.finish();
});
]]
I have changed to using the new method immediate and that also
removed this call.
- 4.2.2.2. Capturing resources
http://dev.w3.org/2006/webapi/DataCache/#capture-failure
Capture failure substeps mistake.
In step 3, both of the arms are the same condition:
[[
3. Pick the appropriate substeps:
If the failure was not caused by a 401 response, then
...
If the failure was not caused by a 401 response, then
...
]]
The second arm should be:
If the failure was caused by a 401 response, then
Fixed.
This was determined from the description of the obsolete event,
which that arm later fires. The description states that the obsolete
event fires when the server returned a 401.
- 4.2.5. Asynchronous Data Cache API
http://dev.w3.org/2006/webapi/DataCache/#eachModificationSince
Typo (missing space).
For the entity entityof each managed ...
should be:
For the entity entity of each managed ...
Fixed.
- 4.2.7. Transaction API
http://dev.w3.org/2006/webapi/DataCache/#transaction-interface
Extra whitespace for the oncommitted event.
[[
IDL
interface CacheTransaction {
void getItem(in DOMString uri, ItemCallback callback);
void release(in DOMString uri);
void commit();
// events
attribute Function oncommitted;
};
]]
This is intentional.
- 4.2.7. Transaction API
http://dev.w3.org/2006/webapi/DataCache/#get-item
Description of getItem has a typo. Part of a sentence is duplicated.
If the resource identified by uri does not exist in this
CacheTransaction object's associated data cache, then the method
must raise data cache object, then the method must raise the
NOT_FOUND_ERR exception and terminate these steps.
should be:
If the resource identified by uri does not exist in this
CacheTransaction object's associated data cache, then the method
must raise the NOT_FOUND_ERR exception and terminate these steps.
Fixed.
Nikunj
http://o-micron.blogspot.com
Re: [DataCache] Some Corrections
- 4.2.2.1. Starting a transaction - Rules should be switched. http://dev.w3.org/2006/webapi/DataCache/#starting-a-transaction first arm: (these should be swapped) 3.3 - Mark transaction as off-line. 3.4 - Create a new cache transaction called transaction and set data cache to be its data cache. second arm: (these should be swapped) 3.4 - Mark transaction as not off-line. 3.5 - Create a new cache transaction called transaction and set data cache to be its data cache. I don't agree. The transaction is off-line, if the off-line flag passed to these steps is set. I think it is unclear without the visual feedback that the spec provides: 1. Mark _transaction_ as not off-line. 2. Create a new cache transaction called _transaction_ and set data cache to be its data cache. You can't set a property on something that isn't yet created. The individual rules 1 and 2 should be swapped. The arms (as I think you interpreted this) are themselves correct. - Joe
Re: [DataCache] Some Corrections
On Dec 16, 2009, at 4:09 PM, Joseph Pecoraro wrote: - 4.2.2.1. Starting a transaction - Rules should be switched. http://dev.w3.org/2006/webapi/DataCache/#starting-a-transaction first arm: (these should be swapped) 3.3 - Mark transaction as off-line. 3.4 - Create a new cache transaction called transaction and set data cache to be its data cache. second arm: (these should be swapped) 3.4 - Mark transaction as not off-line. 3.5 - Create a new cache transaction called transaction and set data cache to be its data cache. I don't agree. The transaction is off-line, if the off-line flag passed to these steps is set. I think it is unclear without the visual feedback that the spec provides: 1. Mark _transaction_ as not off-line. 2. Create a new cache transaction called _transaction_ and set data cache to be its data cache. You can't set a property on something that isn't yet created. The individual rules 1 and 2 should be swapped. The arms (as I think you interpreted this) are themselves correct. Got it Nikunj http://o-micron.blogspot.com
Re: [DataCache] Some Corrections
- 4.2.7. Transaction API
http://dev.w3.org/2006/webapi/DataCache/#transaction-interface
Extra whitespace for the oncommitted event.
[[
IDL
interface CacheTransaction {
void getItem(in DOMString uri, ItemCallback callback);
void release(in DOMString uri);
void commit();
// events
attribute Function oncommitted;
};
]]
This is intentional.
In any case, the leading whitespace is removed in the Editor's draft. Thanks =)
Is there someplace I can go to see the changes made to the draft? Something
like diffs/patches made to a repository? It would be extremely useful to track
the changes.
- Joe
Re: [DataCache] Some Corrections
Great work on the updates! I have a few new corrections that I hadn't yet
submitted and still seem relevant in the new draft.
- 4.3.1 Local Server API
http://dev.w3.org/2006/webapi/DataCache/#request-interface
Make MutableHttpResponse extend HttpResponse? It has methods, but no attributes
to act on.
I'm not fluent in WebIDL just yet, but I've seen this behavior in the spec
already (with DataCacheSync).
interface MutableHttpResponse {
Should become:
interface MutableHttpResponse : HttpResponse {
- 4.3.1 Local Server API
http://dev.w3.org/2006/webapi/DataCache/#registerOfflineHandler
The last sentence says and add server to the cache host. It would be nice to
clarify which cache host is the cache host.
I assume that since the registerOfflineHandler exists on the navigator that
the link between a navigator and a cache host is 1-to-1. I am inexperienced
with Workers, but I overheard there might be a WorkerNavigator interface soon.
Can this be clarified?
Thanks,
Joseph Pecoraro
Re: CfC: to publish LCWD of: Server-Events, Web {SQL Database, Sockets, Storage, Worker}; deadline 15 December
On Dec 16, 2009, at 4:09 PM, ext Charles McCathieNevile wrote: On Wed, 16 Dec 2009 20:46:03 +0100, Ian Hickson i...@hixie.ch wrote: What's the deadline by which we have to have submitted a request? If there's time, I'd like to address Adrian's feedback on the Web Sockets API and then either publish it as LC (if Adrian agrees) or at least WD. I think it makes more sense to publish as a working draft right now. The reality is that wider review that wasn't actually done earlier is often triggered by people holding something up, so assuming that your approach to addressing those comments in one day would result in a draft the entire group thinks is ready if they actually review it carefully seems optimistic at best. Chaals' points are good and if we want a publication of websockets before the December 18 publication request deadline, we should ask Hixie to please prepare a (non-LC) WD of websockets for 22 December publication. Hixie - is this doable? -Art Barstow
Re: [DataCache] CacheTransaction missing committed state
On Dec 10, 2009, at 11:45 AM, Joseph Pecoraro wrote: The specification does not say when a CacheTransaction's status changes to committed. This should be a trivial addition. - 4.2.2. Constructing and modifying data caches http://dev.w3.org/2006/webapi/DataCache/#transaction-status The spec outlines three states of a CacheTransaction: [[ Each cache transaction has a status, which can be either of pending, committed, or aborted. ]] Pending and Aborted states are handled (the last step in each appropriate section): - Starting a Transaction: set as pending - Abort a Transaction: set as aborted - Online Capture Failure: set as aborted I would expect the status to be set as committed as the last step in the Complete a Transaction: http://dev.w3.org/2006/webapi/DataCache/#complete-transaction That would add the following to the list: - Complete a Transaction: set as committed I added this as the last step in the steps to commit a transaction. Nikunj http://o-micron.blogspot.com
RE: [public-webapps] Comment on Widget URI (7)
(bcc public-webapps since not as relevant) I actually think the TAG discussions about versioning and the use of version indicators has been helpful, but it's been hard to drive this to a publication, because there's still some work to be done. However, I think the main insight I've had is that version indicators have limited (but non-zero) utility in situations where the popular language implementations evolve independently of published language specifications. Normally, if language implementations follow language specifications closely, you can use the version number of the specification as a good indicator of the version number of the language. However, in situations like HTML, where the implementations have evolved -- and are likely to continue to evolve -- independently of the versions of the specifications (and each other), the utility of a version indicator is more confusing. Users would *like* a version indicator to correspond to a category of implementation, but the only thing we can give version numbers to realistically are versions of specifications instead. So the utility is limited to controlled situations where the producer of the document with a version indicator really carefully intends to note a specification version, or to cause validation against a particular specification. I'm not quite sure what PC is, to know how this analysis applies to it. Larry -- http://larry.masinter.net -Original Message- From: Marcin Hanclik [mailto:marcin.hanc...@access-company.com] Sent: Wednesday, December 09, 2009 1:37 PM To: Larry Masinter; Robin Berjon Cc: public-webapps@w3.org Subject: RE: [public-webapps] Comment on Widget URI (7) Hi Larry, WOW: It's a pity you were not involved in the discussions around PC's version attribute. Thanks, Marcin From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org] On Behalf Of Larry Masinter [masin...@adobe.com] Sent: Wednesday, December 09, 2009 7:20 PM To: Robin Berjon Cc: public-webapps@w3.org Subject: RE: [public-webapps] Comment on Widget URI (7) FWIW, just to be clear: My comments about versioning and version numbers only apply to the URI scheme, and not to language specifications in general. I haven't reviewed any of the other WebApps documents, except in the context of reviewing the URI scheme. In general, I support appropriate use of version numbers in languages and language specifications, especially since documents and file formats have ample opportunities for in-band version indicators. It's unfortunate that URIs, being compact strings, have no place for version indicators. Larry -- http://larry.masinter.net -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 4:08 AM To: Larry Masinter Cc: public-webapps@w3.org Subject: Re: [public-webapps] Comment on Widget URI (7) Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 7) ** EDITORIAL TITLE ** Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, but there is no versioning of URI schemes. Suggestion: retitle Widget URIs I have provisionally made this change. I agree with Marcos that it would be good to do so throughout the widget family of specifications, especially since there is no reason why versions of its various components need to evolve in synchronised fashion - one could use P+C 4.2 with WARP 2.7. Recommendation to the WG: apply the same change throughout. -- Robin Berjon - http://berjon.com/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
Without the benefit of full context (I only started following this list recently), I'd like cautiously to suggest that the UM solution to Ian's challenge seems awkward because the challenge is itself a poor design, and UM tends to be more difficult to work with when used to implement designs that are poor in the first place. Specifically -- and note that I'm not sure I follow all the details, so I could be missing things -- it seems that the challenge calls for site B to be hard-coded to talk to site A. In a better world, site B would be able to talk to any site that provides feeds in the desired format. In order for this to be possible, the user obviously has to explicitly hook up site B to site A somehow. Ideally, this hook-up act itself would additionally imply permission for site B to access the user's data on site A. The natural way to accomplish this would be for an unguessable access token to be communicated from site A to site B as part of the hook-up step. Once such a mechanism exists, UM is obviously the best way for site B to actually access the data -- CORS provides no benefit at this point. So how does this hook-up happen? This is mostly a UI question. One way that could work with current browsers would be for the user to copy/paste an unguessable URL representing the capability from one site to the other, but this is obviously a poor UI. Instead, I think what we need is some sort of browser support for establishing these connections. This is something I've already been talking about on the public-device-apis list, as I think the same UI should be usable to hook-up web apps with physical devices connected to the user's machine. So imagine, for example, that when the user visits site A originally, the site can somehow tell the browser I would like to provide a capability implementing the com.example.Feed interface. The URL for this capability is [something unguessable].. Then, when the user visits site B, it has a socket for an object implementing com.example.Feed. When the user clicks on this socket, the browser pops up a list of com.example.Feed implementations that it knows about, such as the one from site A. The user can then click on that one and thus hook up the sites. Obviously there are many issues to work through before this sort of thing would be possible. Ian proposed a new device tag on public-device-apis yesterday -- it serves as the socket in my example above. But, how a device list gets populated (and the security implications of this) has yet to be discussed much at all (as far as I know). I just wanted to propose this as the ideal world. In the ideal world, UM is clearly the right standard. I worry that CORS, if standardized, would encourage developers to go down the path of hard-coding which sites they talk to, since that's the approach that CORS makes easy and UM does not. In the long run, I think this would be bad for the web, since it would mean less interoperability between apps and more vendor lock-in. That said, I think it's safe to say that if you *want* to hard-code the list of sites that you can interoperate with, it's easier to do with CORS than with UM. On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close tyler.cl...@gmail.com wrote: On Mon, Dec 14, 2009 at 11:35 AM, Maciej Stachowiak m...@apple.com wrote: On Dec 14, 2009, at 10:44 AM, Tyler Close wrote: On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth w...@adambarth.com wrote: On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees j...@creativecommons.org wrote: The only complaint I know of regarding UM is that it is so complicated to use in practice that it will not be as enabling as CORS Actually, Tyler's UM protocol requires the user to confirm message 5 to prevent a CSRF attack. Maciej's CORS version of the protocol requires no such user confirmation. I think it's safe to say that asking the user to confirm security-critical operations is not a good approach. For Ian Hickson's challenge problem, I came up with a design that does not require any confirmation, or any other user interaction. See: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1232.html That same design can be used to solve Maciej's challenge problem. I see three ways it wouldn't satisfy the requirements given for my CORS example: 1) Fails AJAX UI requirement in the grant phase, since a form post is required. I thought AJAX UI just meant no full page reload. The grant phase could be done in an iframe. 2) The permission grant is intiated and entirely drive by Site B (the service consumer). Thus Site A (the service provider in this case) has no way to know that the request to grant access is a genuine grant from the user. 3) When Site A receives the request from Site B, there is no indication of what site initiated the communication (unless the request from B is expected to come with an Origin header). How does it even know it's supposed to
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Wed, 16 Dec 2009, Kenton Varda wrote: Without the benefit of full context (I only started following this list recently), I'd like cautiously to suggest that the UM solution to Ian's challenge seems awkward because the challenge is itself a poor design, and UM tends to be more difficult to work with when used to implement designs that are poor in the first place. Specifically -- and note that I'm not sure I follow all the details, so I could be missing things -- it seems that the challenge calls for site B to be hard-coded to talk to site A. In a better world, site B would be able to talk to any site that provides feeds in the desired format. A concrete example of the example I was talking about is Google's Finance GData API. There's a fixed URL on A (Google's site) that represents my finance information. There's a site B (my portal page) that is hard-coded to fetch that data and display it. I'm logged into A, I'm not logged into B, and I've told A (Google) that it's ok to give B access to my financial data. Today, this involves a complicated set of bouncing back and forth. With CORS, it could be done with zero server-side scripting -- the file could just be statically generated with an HTTP header that grants permission to my portal to read the page. Another example would be an XBL binding file on hixie.ch that is accessible only to pages on damowmow.com. With CORS I can do this with one line in my .htaccess file. I don't see how to do it at all with UM. So imagine, for example, that when the user visits site A originally, the site can somehow tell the browser I would like to provide a capability implementing the com.example.Feed interface. The URL for this capability is [something unguessable].. Then, when the user visits site B, it has a socket for an object implementing com.example.Feed. When the user clicks on this socket, the browser pops up a list of com.example.Feed implementations that it knows about, such as the one from site A. The user can then click on that one and thus hook up the sites. As a user, in both the finance case and XBL case, I don't want any UI. I just want it to Work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[DataCache] Remove or Replace a Local Server Handler?
There is no way to remove a handler, or all handlers for a particular namespace, after some have been registered. However, this may be a valid design decision, because there probably aren't compelling use cases for removing or replacing handlers. The only time I ran into this need was running multiple tests in a single html file reusing the same namespace (uri). How about an application that wants to seamlessly update its offline handlers without reloading the page? It would need to download a script that removes the old handlers, and installs the new handlers. Does this sound useful and practical? As it stands right now, the Spec should be more specific about how registerOfflineHandler handles multiple handlers registered on the same namespace. var namespace = ... navigator.registerOfflineHandler(namespace, ..., ...); // 1st navigator.registerOfflineHandler(namespace, ..., ...); // 2nd Possible scenarios: 1. The 2nd replaces (and removes) the 1st. 2. Both remain, the earliest registered handler is the final candidate 3. Both remain, the latest registered handler is the final candidate 4. A different heuristic. I would prefer scenario #1. It doesn't make sense to have two different handlers for the exact same namespace. This also cuts down on potential memory leaks, references to dead/unreachable code. - Joe
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Wed, Dec 16, 2009 at 9:25 PM, Ian Hickson i...@hixie.ch wrote: A concrete example of the example I was talking about is Google's Finance GData API. There's a fixed URL on A (Google's site) that represents my finance information. There's a site B (my portal page) that is hard-coded to fetch that data and display it. I'm logged into A, I'm not logged into B, and I've told A (Google) that it's ok to give B access to my financial data. Today, this involves a complicated set of bouncing back and forth. With CORS, it could be done with zero server-side scripting -- the file could just be statically generated with an HTTP header that grants permission to my portal to read the page. ... As a user, in both the finance case and XBL case, I don't want any UI. I just want it to Work. Yet you must go through a UI on site A to tell it that it's OK to give your data to B. Obviously this step cannot be altogether eliminated. What I am suggesting is a slightly different UI which I think would be no more difficult to use, but which would avoid the need to hard-code. In fact, I think my UI is easier for users, because in all likelihood, when you decide I want site B to access my data from site A, you are probably already on site B at the time. In your UI, you have to navigate back to A in order to grant permission to B (and doesn't that also require copy-pasting the host name?). In my UI, you don't have to leave site B to make the connection, because the browser remembers that site A provided the desired capability and thus can present the option to you directly. The down side is that I don't know how to implement my UI in today's browsers.
Re: [DataCache] Some Corrections
I have changed to using the new method immediate and that also removed this call. Immediate looks useful. The specification for immediate is: [[ When this method is called, the user agent creates a new cache transaction, and performs the steps to add a resource to be captured in that cache transaction, and when the identified resource is captured, performs the steps to activate updates for this data cache group. ]] I think this should clarify that it creates an online transaction. - Joe
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
Another example would be an XBL binding file on hixie.ch that is accessible only to pages on damowmow.com. With CORS I can do this with one line in my .htaccess file. I don't see how to do it at all with UM. Seems to me that these examples can just as easily be done with IE's XDomainRequest. Are there examples for CORS which can't be done by UM/XDR ? Cheers devdatta 2009/12/16 Ian Hickson i...@hixie.ch: On Wed, 16 Dec 2009, Kenton Varda wrote: Without the benefit of full context (I only started following this list recently), I'd like cautiously to suggest that the UM solution to Ian's challenge seems awkward because the challenge is itself a poor design, and UM tends to be more difficult to work with when used to implement designs that are poor in the first place. Specifically -- and note that I'm not sure I follow all the details, so I could be missing things -- it seems that the challenge calls for site B to be hard-coded to talk to site A. In a better world, site B would be able to talk to any site that provides feeds in the desired format. A concrete example of the example I was talking about is Google's Finance GData API. There's a fixed URL on A (Google's site) that represents my finance information. There's a site B (my portal page) that is hard-coded to fetch that data and display it. I'm logged into A, I'm not logged into B, and I've told A (Google) that it's ok to give B access to my financial data. Today, this involves a complicated set of bouncing back and forth. With CORS, it could be done with zero server-side scripting -- the file could just be statically generated with an HTTP header that grants permission to my portal to read the page. Another example would be an XBL binding file on hixie.ch that is accessible only to pages on damowmow.com. With CORS I can do this with one line in my .htaccess file. I don't see how to do it at all with UM. So imagine, for example, that when the user visits site A originally, the site can somehow tell the browser I would like to provide a capability implementing the com.example.Feed interface. The URL for this capability is [something unguessable].. Then, when the user visits site B, it has a socket for an object implementing com.example.Feed. When the user clicks on this socket, the browser pops up a list of com.example.Feed implementations that it knows about, such as the one from site A. The user can then click on that one and thus hook up the sites. As a user, in both the finance case and XBL case, I don't want any UI. I just want it to Work. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Wed, 16 Dec 2009, Devdatta wrote: Another example would be an XBL binding file on hixie.ch that is accessible only to pages on damowmow.com. With CORS I can do this with one line in my .htaccess file. I don't see how to do it at all with UM. Seems to me that these examples can just as easily be done with IE's XDomainRequest. How? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
hmm.. just a XDR GET on the file at hixie.ch which allows access only if the request is from damowmow.com ? I am not sure -- is there anything special about XBL bindings which would result in this not working ? Cheers devdatta 2009/12/16 Ian Hickson i...@hixie.ch: On Wed, 16 Dec 2009, Devdatta wrote: Another example would be an XBL binding file on hixie.ch that is accessible only to pages on damowmow.com. With CORS I can do this with one line in my .htaccess file. I don't see how to do it at all with UM. Seems to me that these examples can just as easily be done with IE's XDomainRequest. How? -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Dec 16, 2009, at 11:30 PM, Devdatta wrote: hmm.. just a XDR GET on the file at hixie.ch which allows access only if the request is from damowmow.com ? I am not sure -- is there anything special about XBL bindings which would result in this not working ? If I recall correctly, XDR sends an Origin header, so it would work for this kind of use case so long as the resource is not per-user. XDR essentially uses a profile of CORS with the credentials flag always off. UM is different - it would not send an Origin header. So it would be more difficult to apply it to Hixie's problem. Regards, Maciej Cheers devdatta 2009/12/16 Ian Hickson i...@hixie.ch: On Wed, 16 Dec 2009, Devdatta wrote: Another example would be an XBL binding file on hixie.ch that is accessible only to pages on damowmow.com. With CORS I can do this with one line in my .htaccess file. I don't see how to do it at all with UM. Seems to me that these examples can just as easily be done with IE's XDomainRequest. How? -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)
On Dec 16, 2009, at 9:10 PM, Kenton Varda wrote: Without the benefit of full context (I only started following this list recently), I'd like cautiously to suggest that the UM solution to Ian's challenge seems awkward because the challenge is itself a poor design, and UM tends to be more difficult to work with when used to implement designs that are poor in the first place. Specifically -- and note that I'm not sure I follow all the details, so I could be missing things -- it seems that the challenge calls for site B to be hard-coded to talk to site A. In a better world, site B would be able to talk to any site that provides feeds in the desired format. In order for this to be possible, the user obviously has to explicitly hook up site B to site A somehow. Ideally, this hook-up act itself would additionally imply permission for site B to access the user's data on site A. The natural way to accomplish this would be for an unguessable access token to be communicated from site A to site B as part of the hook- up step. Once such a mechanism exists, UM is obviously the best way for site B to actually access the data -- CORS provides no benefit at this point. CORS would provide at least two benefits, using the exact protocol you'd use with UM: 1) It lets you know what site is sending the request; with UM there is no way for the receiving server to tell. Site A may wish to enforce a policy that any other site that wants access has to request it individually. But with UM, there is no way to prevent Site B from sharing its unguessable URL to the resource with another site, or even to tell that Site B has done so. (I've seen papers cited that claim you can do proper logging using an underlying capabilities mechanism if you do the right things on top of it, but Tyler's protocol does not do that; and it is not at all obvious to me how to extend such results to tokens passed over the network, where you can't count on a type system to enforce integrity at the endpoints like you can with a system all running in a single object capability language.) 2) It provides additional defense if the unguessable URL is guessed, either because of the many natural ways URLs tend to leak, or because of a mistake in the algorithm that generates unguessable URLs, or because either Site B or Site A unintentionally disclose it to a third party. By using an unguessable URL *and* checking Origin and Cookie, Site A would still have some protection in this case. An attacker would have to not only break the security of the secret token but would also need to manage a confused deputy type attack against Site B, which has legitimate access, thus greatly narrowing the scope of the vulnerability. You would need two separate vulnerabilities, and an attacker with the opportunity to exploit both, in order to be vulnerable to unauthorized access. Regards, Maciej
