Re: RfC: pre-LC version of Screen Orientation; deadline August 18
Le lundi 04 août 2014 à 08:19 -0400, Arthur Barstow a écrit : Marcos and Mounir, the Editors of WebApps' Screen Orientation API, consider their spec feature complete with only a few minor [Bugs] open. As such, we seek wide review on their pre-LC version: https://w3c.github.io/screen-orientation/ If you have any comments, please send them to public-webapps by August 18 (and if you and/or your group need more time, please let me know.) We also welcome data about silent reviews, f.ex. I reviewed section N.N and have no comments. A few comments: * Promiseundefined should be Promisevoid from my reading of WebIDL * in the last paragraph of 5.1, the phrase the screen as it is drawn was unclear to me until I read the lock orientation algorithm where the phrase the viewport is drawn made it clearer; maybe the two can be alined * shouldn't the apply an orientation lock algorithm make reference to the event firing? I was having trouble understanding steps 8.2 and 8.3 in the former until I arrived to the latter * while I understand there is ongoing discussion on alignments with DeviceOrientation, I'm less clear there is work to ensure consistency with css-device-adapt; in particular, it seems like it would be useful to understand how the two approaches work together when use simultaneously HTH, Dom
Re: [XHR] XHR 1 / XHR 2
On mar., 2014-02-04 at 17:16 +0900, Jungkee Song wrote: The TR draft says that the URL of the editors draft is: https://dvcs.w3.org/hg/xhr/xhr-1/raw-file/tip/Overview.html I believe it is meant to be: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html That's right. It's a mistake. Is there a way to running-change it? I think the only option is to publish a new WD (based on http://www.w3.org/2003/01/republishing/) It sounds like the group decided to re-use the title XHR Level 1, while it covers the features that used to be in XHR Level 2. That's somewhat confusing (but it may be that it's the least confusing option?). Yes, there's been a decision as such. The history is that the short name XMLHttpRequest was started to be re-used from http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/ which superseded the what had been referenced as XMLHttpRequest 1 back then as well. Well, there is no requirement that re-using the shortname implies re-using the title; but I can imagine that the group wants to use levels to make room for future versions of the spec with new features. In any case, the XMLHttpRequest2 shortname still points to the old XHR Level 2 draft: http://www.w3.org/TR/XMLHttpRequest2/ That should be fixed one way or the other. Thanks for noticing. I'll take care of it discussing with co-editors. Thanks! Dom
January 2014 edition of Standards for Web Applications on Mobile: current state and roadmap
Hi, I've just released the latest iteration of the quarterly overview of W3C technologies that increase the capabilities of Web apps with special relevance on mobile: http://www.w3.org/2014/01/mobile-web-app-state/ This new edition was developed in the Web and Mobile Interest Group, using a dedicated github repository: https://github.com/w3c-webmob/mobile-web-app-standards In particular, the data that is used to build the summary tables of the document is now managed via JSON files, hopefully making it easier to contribute to and re-use it. As always, the document highlight changes since the last edition (4 months ago). Dom
[XHR] XHR 1 / XHR 2
Hi, The TR draft says that the URL of the editors draft is: https://dvcs.w3.org/hg/xhr/xhr-1/raw-file/tip/Overview.html I believe it is meant to be: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html It sounds like the group decided to re-use the title XHR Level 1, while it covers the features that used to be in XHR Level 2. That's somewhat confusing (but it may be that it's the least confusing option?). In any case, the XMLHttpRequest2 shortname still points to the old XHR Level 2 draft: http://www.w3.org/TR/XMLHttpRequest2/ That should be fixed one way or the other. Thanks, Dom
Re: [clipboard] typo in WebIDL
Le mardi 08 octobre 2013 à 03:03 -0700, Hallvord R. M. Steen a écrit : - Original Message - From: Dominique Hazael-Massieux d...@hazael-massieux.fr While parsing en-masse some of the IDLs in JavaScript APIs out there, I stumbled upon an incorrect IDL in http://dev.w3.org/2006/webapi/clipops/clipops.html#dictionary-clipboardeventinit-members Better now, right? http://dev.w3.org/2006/webapi/clipops/clipops.html#dictionary-clipboardeventinit-members Not quite, you removed the attribute keyword from the interface declaration too, where it is needed. cf http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org% 2F2006%2Fwebapi%2Fclipops%2Fclipops.htmloutput=html Dom
September 2013 edition of Standards for Web Applications on Mobile: current state and roadmap
Hi, I've just released the latest iteration of my quarterly overview of W3C technologies that increase the capabilities of Web apps with special relevance on mobile: http://www.w3.org/2013/09/mobile-web-app-state/ It highlights in particular the changes over the past 3 months in the Web platform (on responsive images, resource priorities, performant scrolling and many other). The document itself features a new data point: for each spec it describes, it shows the recent editing activity on the editors draft, based on the commits made in the relevant version control system. If all goes as expected, the next iteration of this document will be published under the banner of the Web and Mobile IG toward the very end of this year (or more likely, very beginning of the next one). Dom
[streams-api] WebIDL bug
Hi,
While parsing en-masse some of the IDLs in JavaScript APIs out there, I
stumbled upon an incorrect IDL in
https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#error-uris_for_streams
First, the stream API should not redefine the URL interface, but instead
define the additional method it needs on a partial interface.
Second the object parameter of createObjectURL should be prefixed with
an underscore since object is a reserved keyword in WebIDL. Although
with a separate overloaded method for stream, using another name for the
parameter will probably work better.
As a result, it should probably looks like
partial interface URL {
static DOMString createObjectURL (Stream stream)
};
HTH,
Dom
[clipboard] typo in WebIDL
Hi,
While parsing en-masse some of the IDLs in JavaScript APIs out there, I
stumbled upon an incorrect IDL in
http://dev.w3.org/2006/webapi/clipops/clipops.html#dictionary-clipboardeventinit-members
Dictionary members are not declared with the attribute keyword.
So
dictionary ClipboardEventInit : EventInit {
attribute DOMString data;
attribute DOMString dataType;
};
should read instead
dictionary ClipboardEventInit : EventInit {
DOMString data;
DOMString dataType;
};
HTH,
Dom
Re: [streams-api] WebIDL bug
Le mercredi 18 septembre 2013 à 09:53 -0400, Anne van Kesteren a écrit : On Wed, Sep 18, 2013 at 4:52 AM, Dominique Hazael-Massieux d...@w3.org wrote: While parsing en-masse some of the IDLs in JavaScript APIs out there, I stumbled upon an incorrect IDL in https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#error-uris_for_streams This specification is obsolete. Nobody should implement it or use it for anything other than historical perspective. Good to know, thanks. Someone should clearly indicate that in the draft. It would also be useful that this be shown in the related TR draft: http://www.w3.org/TR/streams-api/ as well as in http://www.w3.org/2008/webapps/wiki/PubStatus Dom
June 2013 edition of Standards for Web Applications on Mobile: current state and roadmap
Hi all, I've just released another quarterly update to my overview of the most mobile-relevant Web application technologies: http://www.w3.org/2013/06/mobile-web-app-state/ In addition to integrating (hopefully) all the relevant changes to the platform in the past 4 months, it also highlights test suites that can be forked from github, and has a printer-friendly PDF version (generated from the HTML document via princexml). As always feedback, and even better, contributions to the wiki version at http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile, are much welcome. Cheers, Dom
Feb 2013 edition of Standards for Web Applications on Mobile: current state and roadmap
Hi all, I've just released another quaterly update to my overview of the most mobile-relevant Web application technologies: http://www.w3.org/2013/02/mobile-web-app-state/ In addition to integrating (hopefully) all the relevant changes to the platform in the past 3 months, it also highlights specs from the CoreMob 2012 profile, and links to relevant pages on WebPlatform and W3DevCampus. As always feedback, and even better, contributions to the wiki version at http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile, are much welcome. Cheers, Dom
Re: Updated idlharness.js
Le mercredi 23 janvier 2013 à 17:31 +0100, Robin Berjon a écrit : You can find the updated version of idlharness in this branch: https://github.com/w3c/testharness.js/tree/webidl2 Having tested it out, and to make it easiers for others to do so, once you have updated your resources directory to point to the content of that repository, you still need to: * run git submodule init and git submodule update (to fetch the content of the webidl2 project) * replace the previous inclusion of WebIDLParser.js by the path to webidl2.js (by default in the above case, resources/webidl2/lib/webidl2.js) I've run it on the existing test case we have on this for the Battery API: http://w3c-test.org/dap/battery/tests/submissions/anssik/battery-interface-idlharness.html and it gave the same result on the one implementation I know of that API (11 passes and 2 fails). I'll try and do further tests on other APIs (probably getUserMedia). Dom
Nov 2012 edition of Standards for Web Applications on Mobile: current state and roadmap
Hi all, A few days late, but I have just published my quarterly overview of the most mobile-relevant Web application technologies: http://www.w3.org/2012/11/mobile-web-app-state/ As always feedback, and even better, contributions to the wiki version at http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile, are much welcome. Cheers, Dom
Standards for Web applications on mobile devices: August 2012 updates
Hi all, The time of my quarterly release of “Standards for Web Applications on Mobile” has come again; the August 2012 edition of the document is now available at: http://www.w3.org/2012/08/mobile-web-app-state/ I have also created a URI where the latest version of that document will be available from now on: http://www.w3.org/Mobile/mobile-web-app-state/ It incorporates all the changes that have taken place on the various relevant specs and groups since May 2012 (incl 1 Rec, 1 Proposed Rec, 3 CR, 8 FPWD, 1 LC, 2 new charters). That document is extracted from the equivalent page in the W3C wiki where contributions from others are welcomed as always: http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile I'm planning to run another update of that document end of November. Feedback is as always very welcomed. Dom
[IME] WebIDL bugs
Hi, I spotted a few bugs in the WebIDL fragments of the Input Method Editor API draft [1]that I'm reporting below. I'm happy to bring the required changes directly to the draft if that's preferred. -- interface HTMLElement … Object getInputContext (); }; should be partial interface HTMLElement InputMethodContext getInputContext (); }; (assuming this interface is really to be added to HTMLElement) -- CompositionClauseList is a typedef of a sequence type but is used for an attribute; sequences are not appropriate type of attributes, you would want to use an array instead. -- int is not a valid WebIDL type, you would want to use either short, long or long long -- Composition, CompositionCaret and CompositionClause should probably be dictionaries rather than interfaces. That would also allow to define default values directly in the IDL. -- The methods in InputMethodContext uses the in keyword that is no longer a valid WebIDL keyword. Dom 1. http://www.w3.org/TR/2012/WD-ime-api-20120524/
Standards for Web applications on mobile devices: May 2012 updates
Hi all, The time of my quarterly release of “Standards for Web Applications on Mobile” has come again; the May 2012 edition of the document is now available at: http://www.w3.org/2012/05/mobile-web-app-state/ It also incorporates all the changes that have taken place on the various relevant specs and groups since February 2012. That document is extracted from the equivalent page in the W3C wiki where contributions from others are welcomed as always: http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile I'm planning to run another update of that document end of August. Feedback is as always very welcomed. Dom
Draft report for offline apps workshop
Hi, Back in November, we had a workshop on offline Web applications [1] which was the trigger for the creation of the Fixing AppCache community group. Unfortunately, the workshop Chairs have not been in a position to write the workshop report; I've now been tasked to do so, and have produced a first draft on the W3C wiki: http://www.w3.org/wiki/Offline_web_applications_workshop Of course, 5 months later, my memory of the workshop is more than a bit fuzzy, and the notes [2] that were taken during the workshop are a bit sketchy. So, I would very much appreciate reviews of the draft above, and input on what is missing or unclear from the workshop participants. Direct edits in the wiki are best. I would like to publish the official version of this report by the end of next week, so would appreciate any input before EOB next Thursday. Thanks, Dom 1. http://www.w3.org/2011/web-apps-ws/ 2. http://www.w3.org/2011/11/05-offline-minutes.html
Re: CfC: publish Candidate Recommendation of Web IDL; deadline March 26
Le lundi 19 mars 2012 à 06:58 -0400, Arthur Barstow a écrit : Cameron has addressed the comments from Web IDL LC#3 [1] and the bug list only contains two enhancement requests [2]. As such, this is a call for consensus to publish a Candidate Recommendation of Web IDL using the following ED as the basis: http://dev.w3.org/2006/webapi/WebIDL/ This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. Big +1. Dom
Standards for Web applications on mobile devices: February 2012 updates
Hi all, It's been 3 months already since the last update to “Standards for Web Applications on Mobile”; given that Mobile World Congress is happening next week, I thought I would release this update a few days ahead of schedule so that we have a document ready for the congress. So, the February 2012 edition of the document is now available: http://www.w3.org/2012/02/mobile-web-app-state/ Compared to the previous edition [1], it now features detailed info on which mobile browser implement which spec; the data used to compute that information was drawn from CanIUse.com and mobilehtml5.org, completed with more ad-hoc sources. It also incorporates all the changes that have taken place on the various relevant specs and groups since November 2011, and states that widgets can be used to brew coffee in addition to packaging Web apps. That document is extracted from the equivalent page in the W3C wiki where contributions from others are welcomed as always: http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile I'm planning to run another update of that document end of May. Feedback is as always very welcomed. Dom 1. http://www.w3.org/2011/11/mobile-web-app-state.html
Re: Numeric constants vs enumerated strings
Le mercredi 15 février 2012 à 15:08 +0100, Anne van Kesteren a écrit : On Wed, 15 Feb 2012 14:57:00 +0100, Harald Alvestrand har...@alvestrand.no wrote: *This is a call for help from the WEBRTC working group. We are defining a new API (http://dev.w3.org/2011/webrtc/editor/webrtc.html) about:blankwhich has a number of cases where it needs to use arguments, or expose state variables, that can take only a limited set of values. Unless there are strong ties to certain legacy APIs I would suggest using strings. They are easier for developers to author, easier for developers to maintain, easier in the future to extend, and have practically no drawbacks. There are strong ties, in the sense that the said API would be exposing a readyState property (similar to XMLHttpRequest, HTMLMedia, etc). Dom
Re: Standards for Web applications on mobile devices: November 2011 updates
Le mercredi 07 décembre 2011 à 00:01 +, Marcos Caceres a écrit : Although I think this document is quite informative, I again would like to raise objections about lumping app cache and widgets together for the same reasons I raised last time. Your last message on the thread last time made me think your objections had been lifted: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1459.html But I guess I misunderstood it. I'm a bit at loss as to how to make progress on this. However, I don't want to have that argument again: I just want to say I think it's disingenuous (perhaps make it more clear at the top of the document that the document represents mostly your personal opinion?). I'm also concerned that the text that I contributed to the document about the variety of applicability of the technologies has been removed. I did remove it, indeed; listing all the things the document doesn't do didn't seem very helpful to the reader, and seemed redundant with the scoping statement of the document: This document summarizes the various technologies developed in W3C that increase the power of Web applications, and how they apply more specifically to the mobile context. I'm also concerned at use of the terms limited and very limited to label current implementations as being both subjective and relativistic - and it implies that attempts to implement have ceased; particularly next to well deployed, Largely deployed, Growing, and Getting deployed. Either remove that column, or present some data to which you can underpin each of the labels. I agree that the current data are somewhat subjective (and have amended the description of the column in the introduction accordingly). My sources have been: * my personal knowledge of what's available where, and what I've heard is coming soon * http://mobilehtml5.org/ * caniuse.com Ideally, I would like a lot more of the data in that column to come from W3C test suite results, but since we're not there yet, I think subjective (but I'm hoping reasonably well informed) data are probably more helpful to the reader than no data at all. And as any other part of the document, I'm happy to get specific feedback on which of these assessments you think are not in line with the market. Dom
Standards for Web applications on mobile devices: November 2011 updates
Hi all, I've just released a new version of “Standards for Web Applications on Mobile” that takes into account the latest changes in the open Web platform: http://www.w3.org/2011/11/mobile-web-app-state.html Updates since August 2011 [1] includes: * first drafts from Web RTC, of Geo API v2, Vibration API, CSS Device Adaptation * a bunch of last call (Device Orientation, Battery, Web Storage, Touch Events, Web Sockets, ...) * addition of references to accessibility materials on mobile * mention of early work on Web Intents That document is extracted from the equivalent page in the W3C wiki where contributions from others are welcomed: http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile I'm planning to run another update of that document end of February. Feedback is as always very welcomed. Dom 1. http://www.w3.org/2011/08/mobile-web-app-state.html
Re: [DRAFT] Web Intents Task Force Charter
Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : Hi a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. My understanding is that this is not a MUST at all, but the way Web-based services can be added by a user. For a local network approach, my take would be that the browser would be doing the discovery, and possibly offer the user to add local services to the list of available providers when such a service matches the requested intent. Typically, a gallery intent (i.e. requesting a list of medial files) would make the browser list local media galleries (from UPnP) in addition to the registered Web services (e.g. your on-line photo albums). b.) to then subsequently use a registered intent provider the concept is to open that provider, again as a web page in a seperate tab within the UA. From here we can then establish a bi-directional web messaging channel on which we can send and receive messages to communicate to and from that web page that is representing the current local service. I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. Perhaps someone could take the time to describe exactly how a user could communicate with an existing TV device in their home from a web browser supporting web intents based on the above requirements? Here is a rough sketch: * user hits a Web page that wants to load a picture from his gallery * that Web page asks for an intent for media gallery * the browser shows to the user the list of services that can provide media galleries; having detected that there are such services on the local network, it includes these services in the list * the user wants to pick a picture from the gallery hosted on his TV, so picks the TV set in the list of services * from then on, the browser turns the messages sent by the Web page via postMessage() into UPnP requests that the TV set can respond to, and also turns the responses into messages that the Web page can deal with. Dom
Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Le samedi 17 septembre 2011 à 10:30 +0100, Marcos Caceres a écrit : shortcut: if you want to (incorrectly, IMO) continue to lump widgets and app cache, then do so making it clear that this is just one of the use cases for widgets and certainly NOT the primary use case… My document focuses on technologies available to build client-side Web applications for mobile devices; the 52 specifications that the document mentions have all use cases that go well beyond that use case, but I don't think the document would win in usefulness or clarity by stating so for each of these specifications. And please add a separate section just for Widgets in your document that explains the other cases. If by the other cases, you mean: They have been used as server side applications, standalone applications, daemons, and as an extension format. Server-side applications, daemons, and browser extensions are clearly out of scope of the document, so I don't think it would make sense to list them. I agree that there are similarities and overlap for this *one* use case; but again, the use cases of Widgets are far greater than ApplicationCache. To lump them together waters Widgets down to a confusing equivalent to AppCache. The document specifically says that the two approaches are complementary (not redundant), and summarizes what the two technologies provide. I don't see why having them in the same section would mean they're equivalent (again, no more than having SVG and CSS in the same section would mean they're equivalent). If you think the current description doesn't convey clearly enough the differences between the two approaches, I'll be happy to review a better description (either in reply to this mail, or directly in the wiki http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile ). Dom
Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Hi Marcos, Le samedi 03 septembre 2011 à 22:47 +0200, Marcos Caceres a écrit : [sorry for the delay in responding] Thank you for continuing to keep the document up to date. This document is very helpful. Thanks! I have request: can you please ungroup Widgets and HTML's ApplicationCache? They are conceptually different things and have different use cases. I think they are actually not so different, and share many use cases. Widgets are a way to zip up a bunch of HTML, CSS, and JS files that constitute an installable application (or some such). That is, something someone might want to distribute to keep. ApplicationCache can be used to group a bunch of HTML, CSS and JS files that constitue an installable application (e.g. the way the iOS safari browser let you save to your homescreen an offline Web app when an application cache is present). ApplicationCache is cache control thing: it does not package a Web Application; just makes some resources available from the cache (potentially for off-line use). The end user has not control over it and the author can shut it off at any point. The end user *could* have control over it if the user agent let her (the same way a widget user agent could also automatically remove widgets that their authors wish to retract). I don't think there is anything fundamental is the underlying technologies that prevent or facilitate that particular use case. IMO, keeping them together will lead to confusion. The use cases are different: a widget can embed content that uses ApplicationCache, as well as load in proprietary APIs (e.g., WAC). Surely a Web-applicationcached app could also load proprietary APIs. And an application cache could also have a widget as part of its list of cacheable resources. It can be used for defining other classes of applications and formats (e.g., Opera Extensions). I can also imagine using ApplicationCache to do that. Widgets and ApplicationCache differ in some ways (e.g. the security model of widgets is different, widgets currently don't have an origin, etc), but I still don't see how they would fundamentally address different use cases. Dom
Re: Widgets ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)
Le vendredi 16 septembre 2011 à 21:36 +0700, Marcos Caceres a écrit : I think they are actually not so different, and share many use cases. Ok, I strongly object in the strongest of terms to them being put together and I'm more than happy to debate any argument you might have for lumping them together. Here we go :) Well, you are on the program committee of an upcoming workshop that lumps them together: As mentioned above, the World Wide Web Consortium has already developed standards to facilitate the development of off-line Web applications: the HTML 5 Working Group's Application Cache; the Web Applications Working Group's Packaging and XML Configuration. http://www.w3.org/2011/web-apps-ws/ ApplicationCache can be used to group a bunch of HTML, CSS and JS files that constitue an installable application (e.g. the way the iOS safari browser let you save to your homescreen an offline Web app when an application cache is present). I'm sorry, but that has absolutely nothing to do with Application cache. It's done like this: link rel=apple-touch-icon href=/icon.png Sure, that bits helps for having an icon on the homescreen; it's fair to say that rel=apple-touch-icon (and its standard equivalent rel=icon with the sizes attribute) completes ApplicationCache in matching the features that widget packaging provides. But without the application cache, your nice and shiny icon won't load anything if you're not connected; link rel=apple-touch-icon is the equivalent to icon in config.xml, where ApplicationCache is the list of files encoded in the Zip file. ApplicationCache is cache control thing: it does not package a Web Application; just makes some resources available from the cache (potentially for off-line use). The end user has not control over it and the author can shut it off at any point. The end user *could* have control over it if the user agent let her (the But the user agent doesn't let her, because he is mean. And I don't think that is the way the spec was written (though I need to check). But I doubt the spec says anything about that, as it seems the author is king in that situation. I agree that the widget specs say a lot more on application management than ApplicationCache (which more or less only deals with updates and connectivity); but the applicationcache spec certainly doesn't forbid user agents to do smart things with it, as the iPhone implementation shows. As far as I know, (at least) Mozilla is working on saving as Web application, and I would be extremely surprised if they didn't use the applicationcache when available to do that. same way a widget user agent could also automatically remove widgets that their authors wish to retract). There is no provision in any of the specs to do this. Certainly not by design, unlike HTML5. Right; but knowing how application stores tend to have a remove-this-app switch, I'd be surprised if many applications stores based on widgets didn't have a similar ability. IMO, keeping them together will lead to confusion. The use cases are different: a widget can embed content that uses ApplicationCache, as well as load in proprietary APIs (e.g., WAC). Surely a Web-applicationcached app could also load proprietary APIs. How? What mechanism does a proprietary unpacked web application have to do this? And do you have any actual real examples of this happening in the wild? ActiveX and other plugins seem to have provided this for quite some time? Not to mention vendor-prefixed APIs? And an application cache could also have a widget as part of its list of cacheable resources. Sure, they could have bananas too and all sorts of hypothetical things too. But they don't. Right, because that's not terribly useful. But you brought the fact that one technology could embed the other, I didn't. It can be used for defining other classes of applications and formats (e.g., Opera Extensions). I can also imagine using ApplicationCache to do that. You have a wild imagination :) I'm sure there is a good reason why no one has done it. In any case, the document is discussing concrete things, not imaginary things. Right; the document is not discussing the fact that widgets can also be used for creating browser extensions, or providing server-side lump of content. It's discussing packaging web applications for offline usage. Please base the document on real world things, not on things you imagine. I don't think I'm imagining that both widgets and applicationcache provide a way to package Web applications for users. At least, you still haven't convinced me that they don't. I don't think that lumping them together means they are the same technology covering exactly the same use cases, otherwise my document would also assert that SVG, canvas and CSS are the same. Widgets and ApplicationCache differ in
Standards for Web applications on mobile devices: August 2011 updates
Hi all, I've just released a new version of “Standards for Web Applications on Mobile” that takes into account the latest changes in the open Web platform: http://www.w3.org/2011/08/mobile-web-app-state.html Updates since May 2011 [1] includes: * Addition of a new section on technologies useful for device adaptation * Addition of the new W3C Community Groups as a way to start standardization work in W3C * Four new APIs from the Web Performance Working Group: Performance Timeline, User Timing, Efficient Script Yielding and Timing control for script-based animations * The first editor draft of Web Real-Time Communication * A number of other documents made progress on the Recommendation track (WOFF, Contacts API, DeviceOrientation Event, Network Information API, the family of Widgets specifications) * Addition of the proposed work on model-based user interfaces * Updates based on the adoption of the new Device APIs Working Group charter That document is extracted from the equivalent page in the W3C wiki where contributions from others are welcomed: http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile I'm planning to run another update of that document end of November. Feedback is as always very welcomed. Dom 1. http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0743.html
Re: Battery Status API vs. Geolocation API
Hello Andres, The Battery Status API is deliverable of the Device APIs Working Group, so I'm copying the group's list public-device-a...@w3.org. (keeping public-webapps in BCC FYI) Dom Le dimanche 05 juin 2011 à 22:44 -0700, Andres Riofrio a écrit : I have some comments on the Battery Status API. I was wondering why it was that the battery status API is exposed using Events (and adding an additional requirement When an event listener is registered with the event type batterystatus, then the User Agent must dispatch a BatteryStatusEvent event immediately.), when the Geolocation API is exposed using a getCurrent and a watch function, that invoke a callback when the information is available. Is there a rationale for using a different paradigm than the (kind of) established Geolocation API? I think it'd be better (saner for developers) to use the same paradigm. Further, doesn't the requirement that a BatteryStatusEvent be dispatched immediately incur a synchronous delay as the browser gets that information? That is, nothing else can happen because the event must be dispatched immediately. I might understand wrongly, but if this is the case, I think it should be changed to retrieves the relevant information and dispatches a BatteryStatusEvent asynchronously. Andres Riofrio
Re: Publishing an update of File API spec
Le lundi 06 juin 2011 à 08:55 -0400, Arthur Barstow a écrit : The last publication of the File API spec [ED] was last October so it would be good to publish a new Working Draft in w3.org/TR/. Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not appear to identify any open issues, does the spec meet the Last Call Working Draft requirements (as, indicated in previous CfCs for LCWD such as [CfC-LCWD])? Note that the Web IDL fragments in that document are not valid: http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org% 2F2006%2Fwebapi%2FFileAPI%2Finput=output=html I would fix them myself, but last time I did it, that created troubles for the editor; I think the fixes are likely the same as the ones that were reverted back then: http://dev.w3.org/cvsweb/2006/webapi/FileAPI/Overview.html.diff?r1=1.55;r2=1.57;f=h Dom
Status of URL Interface?
Hi, There was discussion some time ago about specifying a URL interface, based I think on the draft proposal at https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=enpli=1 Is this something that the Web Apps Working Group is planning to work on? If not, does anyone know the status of this effort? Thanks, Dom
Update to Standards for Web applications on mobile
Hi, Back in February, I announced here a first release of a document compiling all the technologies that I had identified as relevant to the development of Web applications on mobile devices: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0650.html I have just released an updated version of that report integrating the changes from the last 3 months: http://www.w3.org/2011/05/mobile-web-app-state.html It highlights the said changes as part of the introduction, for those who would want only the updates since the last release. That document is extracted from the equivalent page in the W3C wiki where contributions from others are welcomed: http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile Many thanks to Art and Marcos for having already contributed their updates there! I'm planning the next release of this document end of August, including a first pass at a gap analysis, highlighting currently missing features; I'm very interested on feedback on this in particular, but on the rest of the document in general as well. There is still some feedback that I haven't addressed from last time which I plan on integrating in the next release as well: * integration of accessibility considerations (e.g. WAI ARIA) * potential integration of InkML as an exchange format for touch input * potential integration of microdata * some I18N considerations? Dom
Re: Overview of W3C technologies for mobile Web applications
Le vendredi 13 mai 2011 à 12:19 -0400, Arthur Barstow a écrit : Thanks for creating this Dom (FYI, I made some edits and updates yesterday). Thanks! As you may have seen, I've just released a new version of that document which includes your updates http://www.w3.org/2011/05/mobile-web-app-state.html Re the overall positioning and scope of the document, it seems like the document would be more useful if it was positioned more generally as a survey of Standards for Web Applications. The definition of mobile, in the context of devices, changes rapidly and it wasn't so long ago that mobile devices meant monochrome phones running a WAP stack. If any of the specs used for Web applications have particularly relevant mobile characteristics/constraints, that could be documented in a new Mobile/Mobility column. Given that the time I can spend on this is funded for its mobile orientation angle, I would rather its focus as is; now, if there is a way to extract a mobile oriented from a more generic document, I would be more than happy to contribute to the generic document. If someone creates such a generic document with enough hooks for me to extract the mobile-focused document, I'm also fine with producing the tool that does the extraction. But I probably wouldn't have the cycles to migrate the current mobile-focused document into a more generic one with the proper hooks. HTH, Dom
Re: Overview of W3C technologies for mobile Web applications
Le jeudi 24 février 2011 à 16:03 +0100, Dominique Hazael-Massieux a écrit : As part of a European research project I'm involved in [1], I've compiled a report on the existing technologies in development (or in discussion) at W3C for building Web applications and that are particularly relevant on mobile devices: http://www.w3.org/2011/02/mobile-web-app-state.html [...] I can also look into moving it in a place where a larger community could edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is interested in contributing. Since I've received at least one offer to help keeping the page up to date if moved to a wiki, I've moved a copy of the document above to the wiki page at http://www.w3.org/wiki/Standards_for_Web_Applications_on_Mobile In the upcoming two weeks, I'll bring a number of updates to the document for a new stable release at this of the month. Any help in bringing the document up to date will be very welcomed! Dom
[Web Sockets] Bug in Web Sockets API WebIDL
Hi, The WebIDL declaration under The WebSocket interface in http://dev.w3.org/html5/websockets/ has a minor bug. It doesn't use the proper syntax for extended attributes: it does [A][B] where the WebIDL grammar is [A,B] in [Constructor(in DOMString url, in optional DOMString protocols)] [Constructor(in DOMString url, in optional DOMString[] protocols)] (found with the WebIDL checker at http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org% 2Fhtml5%2Fwebsockets%2Finput=output=html ) HTH, Dom
Re: Overview of W3C technologies for mobile Web applications
Hi Charles, Le mardi 08 mars 2011 à 21:14 -0800, Charles Pritchard a écrit : InkML is a development relevant to mobile Web. Tablets and other input-rich devices are gaining in acceptance (and becoming easier to purchase). InkML is one of the few specs to put forward both a stream-based and archive-oriented format. I see that there is ongoing discussions around the relationship between InkML and DOM touch events: http://lists.w3.org/Archives/Public/www-multimodal/2011Feb/0004.html This may indeed make InkML a promising lead for capturing user input; I'll see if I find a way to integrate it in the mobile web apps standards document http://www.w3.org/2011/02/mobile-web-app-state.html If anyone has more input on how developers would actually use InkML as part of their Web applications on mobile devices, that would be most useful. Thanks, Dom
Re: Overview of W3C technologies for mobile Web applications
Hi Ben, Le vendredi 25 février 2011 à 14:04 +, Ben Laurie a écrit : As part of a European research project I'm involved in [1], I've compiled a report on the existing technologies in development (or in discussion) at W3C for building Web applications and that are particularly relevant on mobile devices: http://www.w3.org/2011/02/mobile-web-app-state.html Nothing on security? It does mention the work on CORS and the work around widgets security, but there is no dedicated section on security — I'm not sure what would appear there that would be particularly relevant on mobile devices, any suggestion? Thanks, Dom
RE: Overview of W3C technologies for mobile Web applications
(trimming CC) Hi Somnath, Le samedi 26 février 2011 à 12:45 +0530, Somnath Chandra a écrit : This document is an excellent document. It gives present state-of-the art and roadmap ahead for development of Mobile Web. Implementation of Mobile Web with South Asian complex scripts is a challenging task. In India we have 22 constitutionally recognized languages and 12 scripts. Therefore , as a lead in W3C Mobile Web , Internationalization requirements and associcated complexities for Mobile Web implementation may also be a part of your document. If you desire , Swaran Lata , Director W3C India Country Manager and myself Dr. Somnath Chandra , Dy. country manager , W3C India would be happy to contribute. It would be indeed very useful to get your perspectives on what standards could help in getting mobile Web applications deployed across many more languages and scripts. I know Richard Ishida already provided some input on the bricks needed to display non-Latin 1 pages in a blog post: http://rishida.net/blog/?p=445 I wonder if this could be a starting point for something more formal that could help in this space? (I expect I'll get to hear some of your thoughts on this at the Mobile Web Apps camp in WWW2011 http://www.w3.org/2011/03/w3c-track.html) Thanks, Dom
Re: Overview of W3C technologies for mobile Web applications
Hi Paul, Le vendredi 25 février 2011 à 16:53 +0100, Paul Libbrecht a écrit : I definitely agree this is a useful deliverable; I wish more EU projects be as careful in their survey as that! Thanks! I was looking to see if MathML was mentioned (I think it should as a future technology but it has almost zero coverage on the mobile world yet). But I realize that HTML is also not decomposed there. It seems to be assumed and mentioned in many places. Am I right? The approach I've taken is to highlight the most relevant features in specs across the large number of W3C groups for developing applications on mobile devices. While there are certainly use cases for display maths as part of mobile app (e.g. for education), it hasn't struck me as a particularly mobile-relevant feature, which is why I haven't included it. The fact that it has very little implementation on mobile browsers doesn't help either. But I'd be happy to reconsider that position if you have further input on this :) I would think a feature-by-feature analysis of what's in HTML4/5/XHTML and works on mobiles would be rather useful. I would certainly love that as well, but I think it is also beyond what I can possibly manage :) That said, part of the MobiWebApp project is also to help on the development of test suites for the relevant technologies, so maybe we'll get some of that picture when this makes more progress. Thanks for the feedback, Dom
Overview of W3C technologies for mobile Web applications
(bcc to public-html and public-device-apis; please follow-up on public-webapps) Hi, As part of a European research project I'm involved in [1], I've compiled a report on the existing technologies in development (or in discussion) at W3C for building Web applications and that are particularly relevant on mobile devices: http://www.w3.org/2011/02/mobile-web-app-state.html It is meant as a picture of the current state as of today, based on my own (necessarily limited) knowledge of the specifications and their current implementations. I'm very much looking for feedback on the document, the mistakes it most probably contains, its overall organization, its usefulness. I can also look into moving it in a place where a larger community could edit it (dvcs.w3.org, or www.w3.org/wiki/ for instance) if anyone is interested in contributing. I'll likely publish regular updates to the document (e.g. every 3 months?), esp. if it helps sufficiently many people to understand our current ongoing activities in this space. Thanks, Dom 1. http://mobiwebapp.eu/
Re: Testing Requirements
Hi Marcos, Le mardi 15 février 2011 à 13:19 +0100, Marcos Caceres a écrit : Can we please get a full rundown of the systems available on test server. Can we also have all the details about getting access to the server, etc. Here is what I know off the top of my head: * the content on w3c-test.org reflects automatically the content of a number of selected repositories of dvcs.w3.org ; the selection of repositories can be extended by asking sys...@w3.org and/or Francois (f...@w3.org) * w3c-test.org can be used to host any static files * it can be used to host PHP scripts, but these scripts need to be reviewed/approved by W3C Staff — this is done transparently, i.e. whenever a PHP script is committed, a number of us get a notification, we review the changes and upon approval the PHP script is updated on the server side * the content of w3c-test.org is also available as www.w3c-test.org , www1.w3c-test.org and www2.w3c-test.org to allow testing cross-domain operations * it is also available under https as https://w3c-test.org/ (I see that Art documented most of this in http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought this ought to be confirmed on the list) We would rather keep as many of the scripts in PHP to avoid making the set up and maintenance of the server more complicated, but if/when we need to run scripts in another language (e.g. Python), this can be brought back on the table. Dom
Rechartering Device APIs Policy Working Group
Hi, The Device APIs and Policy Working Group has been chartered in 2009 [1] to create client-side APIs to interact with device hardware, services and applications (e.g. camera, addressbook). As the group's initially allotted time runs out in June this year, we are discussing a number of changes to our official mission so as to better reflect the work we have actually been doing as well as to seek involvement from a larger set of stakeholders, in particular from potential implementors. The Chairs and Staff Contacts of the group have proposed a draft charter as a starting point for these discussions: http://www.w3.org/2010/11/DeviceAPICharter.html This proposed charter charter offers the following changes: * removal of the work on a policy framework — that work item has proved to be source of confusion about the scope of the group, and has effectively already been abandoned by the group * renaming the group to Device APIs Working Group (with its short name remaining DAP) * a better definition of the constraints on security and privacy the group is working under * a tighter scope and definition of APIs The discussions on this new charter have just started in the group, but we're hoping to get input and feedback from outside the group early on, in order to ensure that those interested by the relevant APIs but not yet in the group feel comfortable in the direction of this new charter. Please send feedback either directly to the group public mailing list (public-device-a...@w3.org) or to the Chairs and Staff Contacts (ro...@berjon.com, t...@w3.org, d...@w3.org, frederick.hir...@nokia.com). Thanks, Dominique Hazael-Massieux, Staff Contact of the Device APIs and Policy Working Group 1. http://www.w3.org/2009/05/DeviceAPICharter
HTML Media Capture draft from Device APIs and Policy Working Group
Hello WebApps WG, The Device APIs and Policy Working Group has published a new draft called HTML Media Capture on which we think we'll need to coordinate with your group: http://www.w3.org/TR/2010/WD-html-media-capture-20100720/ That document defines a mechanism to bind an input type=file with a set of well-defined accept attribute values, completed by a mime type parameter (capture), with an extended file picker (that integrates access to on-device microphones, cameras and camcorder) and resulting in a MediaFile object that extends the File object from the FileAPI. Feedback from the WebApps Working Group on our proposed extension to the File interface (in the MediaFile interface) would be very much welcomed. Let me know if any additional details would be useful, Dom, on behalf of the Device APIs and Policy Working Group
Re: Automatic translation/validation of WebIDL documents
Le mercredi 02 juin 2010 à 13:40 +0200, Florian Stegmaier a écrit : My overall question is, if you have any experience with WebIDL parser, or perhaps could point me to a project, which is most up-to-date to the current version of the WebIDL specification? I have also tried to validate our API spec using the validator of [5], but i am not quiet sure if this validator is able to handle the array definitions. Do you know also a validator, to make sure if our spec is correct? My understanding is that the WebIDL spec still needs to be updated to reflect the addition of arrays (i.e. no change in that regard since [4]). In particular, their lack of formal definitions in the grammar means that WIDLproc [5] doesn't accept them, which also implies that the on-line WebIDL checker marks them as invalid: http://www.w3.org/2009/07/webidl-check Dom [1] http://www.w3.org/2008/WebVideo/Annotations/ [2] http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/LC/Overview.html (LC version) [3] http://code.google.com/p/es-operating-system/wiki/esidl [4] http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0092.html [5] http://widl.webvm.net/
IndexedDB WebIDL bugs
Hi, Glancing quickly at the editors draft of http://dev.w3.org/2006/webapi/WebSimpleDB/ and with help from the WebIDL checker, I've found the following problems: * none of the interfaces/exceptions are marked with the extended attribute [NoInterfaceObject] — I doubt they are all meant to be visible in the global namespace * The IDBDatabaseException Interface uses the attribute keyword for code and message - exceptions don't have attributes, the keyword should be removed * IDBDatabaseSync.createObjectStore uses an extended attribute [Null=Null] on its second parameter - I suspect it was meant to be [TreatUndefinedAs=Null], and if so, the type of the parameter should be DOMString? rather than DOMString Based on the discussions on the list, and as the beginning of 3.3 seems to allude to, synchronous operations are only going to be used in Workers; I suggest to state that clearly, and also to start the first example of the spec with the async example if that's the one that is most likely to be used. Dom
Re: Server Sent Events vs Web Sockets?
Le lundi 12 avril 2010 à 17:47 +, Ian Hickson a écrit : Server sent events doesn't require any change to the network, it's compatible with almost any setup that uses HTTP today. Web Sockets requires that intermediaries support full-duplex connections. Server sent events is compatible with today's HTTP servers. Web Sockets requires new Web Socket servers. OK — in other words, Server Sent Events should be easier to deploy. Server Sent Events has a variety of features that Web Sockets lacks by design, such as reconnection, event IDs, and the ability to send arbitrary events. So, Server Sent Events adds to Web Sockets a specific protocol for dealing with events, a useful pattern to optimize. These differences mean that there will likely be a reason for both to exist for a long time. Yeah, I didn't mean to question that; I'm just trying to see the full picture. Currently, the two documents don't reference each other at all; some clarification of their relationship in the specs themselves would be useful, I think. They're part of the same document: http://www.whatwg.org/specs/web-apps/current-work/complete.html#comms Whether you consider them as sections or documents, I think it would still be useful to document (however briefly) their interrelationship (as you just did). Thanks! Dom
Server Sent Events vs Web Sockets?
Hi, Given the overlap I perceive between Server Sent Events and the Web Sockets spec, I would be interested to know what role Server Sent Events fills that Web Sockets doesn't. I understand that Server Sent Events allow for unidirectional communication with the server, while Web sockets is bidirectional, and SSE is purely HTTP-based, while Web sockets is made to switch to a lower level protocol, but this all points to SSE being a subset (feature-wise) of Web sockets. Is it only a question of timing? i.e. SSE filling the role of Web Sockets while Web Sockets is being finalized? Currently, the two documents don't reference each other at all; some clarification of their relationship in the specs themselves would be useful, I think. Thanks, Dom
Re: [WARP] comment on subdomains
Le jeudi 04 mars 2010 à 17:03 +0100, Robin Berjon a écrit : Good suggestion, the latest ED reflects the above change plus another reference where subdomains are defined. Please let us know if that works for you! It does, thanks! Dom
Re: [WARP] comment on subdomains
Le jeudi 04 mars 2010 à 15:51 +0100, Robin Berjon a écrit : On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote: A quick comment after re-reading WARP at the invitation of Robin to DAP [1]: I don’t think the notion of subdomain is well-defined; is w3.org a subdomain of .org? is co a subdomain of co.uk? I assume they are in the sense of the spec, but if that’s so, it doesn’t match the “street” meaning of the word “subdomain”; this matters in particular in section 7 (rules for granting access), since this has an impact on how a user agent decides to grant access to a network resource. Given that IP addresses are allowed, the algorithm to determine if something is a subdomain of another domain is as simple as looking to the last dot in the authority component. That's a fair point. Would referencing RFC 1034 in that section address your concern? I would rather not have to define subdomain ourselves but rather reuse what already exists! Sounds good to me, although I think I would also rephrase somewhat the algorithm, à la: * the URI's scheme component is the same as scheme; and * if subdomains is false or if the URI's host component is not a domain name (as defined in RFC1034), the URI's host component is the same as host; or * if subdomains is true, the URI's host component is either the same as host, or is a subdomain of host (as defined in RFC1034); and * ... Dom
Re: [widgets] Testing infrastructure for Widget Access Request Policy (WARP) spec
Hi Art, Marcos, Le jeudi 11 février 2010 à 13:00 -0500, Arthur Barstow a écrit : During the 4-Feb-2010 widgets voice conference, we discussed how to test WebApps' WARP spec [WARP] and Marcos raised concerns about how to test the spec given it requires at least two domains to test against since the test cases will make cross-domain requests: http://www.w3.org/2010/02/04-wam-minutes.html#item07 Marcos indicated you had mentioned some related work (i.e. cross- domain testing) has been done at the W3C thus we are wondering if you have a testing infrastructure we can use/leverage. Hmm... I'm not sure what Marcos was referring to; in any case, it seems to be that the simple way to do cross-domain testing would be to host tests on both www.w3.org and dev.w3.org? Dom
Re: [widgets] Testing infrastructure for Widget Access Request Policy (WARP) spec
Le lundi 15 février 2010 à 12:46 +0100, Marcos Caceres a écrit : During the 4-Feb-2010 widgets voice conference, we discussed how to test WebApps' WARP spec [WARP] and Marcos raised concerns about how to test the spec given it requires at least two domains to test against since the test cases will make cross-domain requests: http://www.w3.org/2010/02/04-wam-minutes.html#item07 Marcos indicated you had mentioned some related work (i.e. cross- domain testing) has been done at the W3C thus we are wondering if you have a testing infrastructure we can use/leverage. Hmm... I'm not sure what Marcos was referring to; in any case, it seems to be that the simple way to do cross-domain testing would be to host tests on both www.w3.org and dev.w3.org? I might be wrong, but I could have sworn that at TPAC we discussed the formation of a working group that was going to work on test suites across the W3C? Oh, sorry, I thought domains related to DNS rather than W3C domains :) There has been discussion of an effort to build a cross-working groups test harness that could host test suites and gather test results, in a generalized and more robust approach to what the Mobile Test Harness [1] offered. Philippe Le Hégaret has been driving this to the best of my knowledge, so I'm copying him here in case he is in the position to give an update on this. I'm not sure this involved the creation of a Working Group, but I might be wrong. HTH, Dom 1. http://www.w3.org/2007/03/mth/harness
[widgets-interface] Marking Widget as [NoInterfaceObject]
Hi, http://www.w3.org/TR/2009/CR-widgets-apis-20091222/#the-widget-interface currently declares the Widget interface without extended attributes. I believe it is not the goal of the specification to expose the interface itself in the global namespace, so I think it should be marked with a [NoInterfaceObject] extended attribute. There is also a typo in the note under the declaration of the interface: e.g., a user agent can to support (probably missing the verb choose). Dom
Re: DAP and security (was: Rename File API to FileReader API?)
Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit : The abstraction of the security concerns within a policy may allow delegation of the security to some third parties. There are usually no third parties to delegate to. That’s true to a certain extent, but a reason for that might well be that the Web platform hasn’t left enough room for third parties in that realm. One could very well imagine that by allowing a certain level of abstraction in security concerns, we would allow businesses to offer guarantees against data-loss or data-thief if the user install a third-party extension that would check Web sites based on a number of their security aspects. I’m pretty sure I don’t like all the implications of such a system, and I’m generally rather in the skeptic side when it comes to the use of a full-blown policy framework for the Web; but I don’t think it’s fair to conclude that it is not useful simply based on the fact that it hasn’t been put to use yet, esp. if it’s currently difficult or impossible to put it to use. Dom
File upload superseded by File API?
Hi, My understanding is that the File Upload spec is now superseded by the File API spec, but http://www.w3.org/TR/file-upload/ doesn't redirect to http://www.w3.org/TR/FileAPI/ I guess ideally the latter would have used the former has previous version, but since it’s too late for that, I think the group should at least ask the W3C Webmaster to do the redirect from the former to the latter. Thanks, Dom
Re: [widgets] Request for Comments: LCWD of Widget Interface; deadline 8 December 2009
Le mardi 17 novembre 2009 à 12:01 -0500, Arthur Barstow a écrit : And test suite files are now online [2]. [[ ++ MWTS WG ]] [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/ To be fair, that work only represents Marcos’s efforts so far — I did contribute some test cases, but they haven’t been integrated or reviewed yet. Definitely Marcos++ :) Dom
Work on Read before/separtely from Write? (was: Rename “File API” to “FileReader API”?)
Le vendredi 13 novembre 2009 à 02:28 -0800, Arun Ranganathan a écrit : Discussion about renaming shows that there isn't really consensus about a name change [1][2], so I haven't proceeded with one. I'd rather proceed without a name change for now, but work towards evolving file write capabilities safely for the web based on this API. I'm not averse to multiple specifications (and better naming later on), if we find that use cases diverge between groups. Some editorial help has been forthcoming [3], which is welcome. It certainly seems entirely reasonable not to change the title now (i.e. before the FPWD), given indeed lack of consensus on the topic. I tend to think that it’s probably better to work separately on the read and write access (independently on the questions of which WG the work happens), since read-access seems to be closer to be ready and well-understood than writing — I guess that’s really what needs to be discussed now rather than the title of the spec which really is only a corollary issue. Dom [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0604.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0572.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0558.html
DAP and security (was: Rename “File API” to “FileReader API”?)
Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit : I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. Frederick already mentioned this isn’t the case at all, and I want to strongly reject the notion that DAP is considering security as an after-the-fact or out-of-band aspect in the design of its APIs. Our charter clearly stipulates that our policy model “must be consistent with the existing same origin policies (as documented in the HTML5 specification), in the sense that a deployment of the policy model in Web browsers must be possible”. In fact, most of models that have been discussed in this thread to reduce the risks exposed by new APIs (sandbox for writing, user interaction or markup-based element for sharing data) were already mentioned as options by DAP WG participants during our F2F last week. More generally, I don’t think assuming that DAP would create worse/less secure APIs than WebApps or any other group would is either right nor useful to ensure a good collaboration between our groups. And clearly, we will actively be seeking feedback and input from the WebApps Working Group when we produce new APIs, which should also contribute to reduce the fears that we would get it all wrong :) Regards, Dom
Re: [widgets interface] Tests generated from WebIDL
Hi Marcos, I saw that the test suite for TWI was discussed on the WebApps call today: http://www.w3.org/2009/11/12-wam-minutes.html#item05 Since the discussion didn’t allude at all to my mail below about generated test cases, I thought I would point you to it explicitly in case you had missed it. Dom Le mercredi 28 octobre 2009 à 22:43 +0100, Dominique Hazael-Massieux a écrit : Using wttjs [1], I have generated a bunch of low-level test cases for the Widgets Interface spec, based on its WebIDL, and uploaded them to: http://dev.w3.org/2006/waf/widgets-api/tests/idl-gen/ Since I don’t have a widgets engine that would implement the spec, I haven’t been able to check if they detect anything remotely useful, but I’m hoping they do — maybe someone with such a runtime engine could load http://dev.w3.org/2006/waf/widgets-api/tests/idl-gen/all.html and see if any tests pass? I guess the tests might need to be wrapped up in a widget for that, in which case I have one available at: http://dev.w3.org/2006/waf/widgets-api/tests/idl-gen/idl.wgt (obviously, these tests wouldn’t be enough to test the semantics of the Javascript interface, but hopefully they can serve as a basis for ensuring everyone is using the same interfaces) Side-note: The Widgets Interface spec uses the old AE title in its title element. Dom 1. http://suika.fam.cx/www/webidl2tests/readme
Re: [widgets interface] Tests generated from WebIDL
Le jeudi 12 novembre 2009 à 17:35 +0100, Marcos Caceres a écrit : On the other hand, automated test generation can generate a large number of test cases and is less prone to human errors. But, at the same time, it cannot test some things that are written in the prose. For example, a AU must not fire Storage events when first populating the preferences attribute. This is impossible to express in IDL. I complete agree that manual tests bring a lot of value, but I think it would be unwise to refuse automated tests that express exactly what the spec expresses — in particular, they can be extremely useful to detect bugs in the WebIDL defined in the specs, bugs that are extremely unlikely to be detected through manual testing. In other words, I don’t see why manually and automatically created tests are mutually exclusive, and I see very clearly how they can complete each other. Dom
Re: [widgets interface] Tests generated from WebIDL
Le jeudi 12 novembre 2009 à 17:52 +0100, Marcos Caceres a écrit : I complete agree that manual tests bring a lot of value, but I think it would be unwise to refuse automated tests that express exactly what the spec expresses — in particular, they can be extremely useful to detect bugs in the WebIDL defined in the specs, bugs that are extremely unlikely to be detected through manual testing. Like I said, we are certainly not rejecting automated testing, we (me) are just not up to that stage yet. I completely agree with you that it will help us find more potential bugs in the IDL itself. I see, sorry I misunderstood then :) Thanks for the clarification, Dom
Rename “File API” to “FileReader API”?
Hi, I alluded to this during the joint F2F meeting between WebApps and DAP last week, but thought I would make the proposal more formally: given that the current “File API” [1] really defines a FileReader interface, and given that DAP is supposed to come up with a more generic filesystems API (including the possibility to write to files), I suggest that “File API” should be renamed to “FileReader API.” Dom 1. http://dev.w3.org/2006/webapi/FileAPI/
Re: Rename “File API” to “FileReader API”?
Le mardi 10 novembre 2009 à 02:27 -0800, Maciej Stachowiak a écrit : At TPAC, I recall that we proposed drawing the line between file reading/writing on the one hand (presumably to go in the current File API spec) and filesystem access (including messing with directories, mountpoints, file renames etc) to be done in the Filesystem API spec. Do we need further discussion to settle what goes in which spec? My understanding of the line was different: FileReader on the one hand, on a fast track in WebApps, and a more generic file interaction APIs (including file writing, and file systems operations as needed by well-defined use cases) in DAP. So we probably need further discussion if that’s not a shared understanding :) That said, unless the plan is to include file writing in the 1.0 version of the current File API (which I think was not the case wherever it gets done), I think my suggestion of renaming it to FileReader still makes sense. Dom
Re: CfC: to publish First Public Working Draft of File API spec; deadline Nov 10
Le mardi 03 novembre 2009 à 21:27 -0800, Arthur Barstow a écrit : This is a Call for Consensus (CfC) to publish the First Public Working Draft (FPWD) of the File API spec, latest Editor's Draft at: http://dev.w3.org/2006/webapi/FileAPI/ My understanding is that the FPWD would have a “security considerations” section, as alluded to by an action item Arun took during the joint DAP/WebApps meeting last week: http://www.w3.org/2009/dap/track/actions/40 Given that I don’t see it in the editors draft, is this something that we’re dropping from FPWD? dropping altogether? just something that was missed in the process? (in the two former cases, I think this should at least be noted to DAP) Dom
Re: Use Cases and Requirements for Saving Files Securely
Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit : Some use cases: […] * Ability to write a Web-based photo management application that handles the user's photos on the user's computer * Ability to expose audio files to native media players * Ability to write a Web-based media player that indexes the user's media Note that these three use cases would be potentially better addressed by the potential Media/Gallery API the group is supposed to work on (“Gallery API, an API to manage the local media file storage” in our charter [1]). Dom — hello DAP’s ISSUE-39 1. http://www.w3.org/2009/05/DeviceAPICharter
[WARP] IRI normalization only for HTTP*?
Hi, WARP requires normalization of IRI using ToASCII only for HTTP and HTTPS uris — is there any reason for that? Dom
Re: [FileAPI] Latest Revision of Editor's Draft
Le lundi 26 octobre 2009 à 05:24 -0700, Arun Ranganathan a écrit : The latest revision of the FileAPI editor's draft is available here: http://dev.w3.org/2006/webapi/FileAPI/ The WebIDL checker identifies a couple of simple bugs in the draft: http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org% 2F2006%2Fwebapi%2FFileAPI%2Foutput=html (a missing “;” and an erroneous usage of “attribute” inside an Exception). Dom
[widgets interface] Tests generated from WebIDL
Hi, Using wttjs [1], I have generated a bunch of low-level test cases for the Widgets Interface spec, based on its WebIDL, and uploaded them to: http://dev.w3.org/2006/waf/widgets-api/tests/idl-gen/ Since I don’t have a widgets engine that would implement the spec, I haven’t been able to check if they detect anything remotely useful, but I’m hoping they do — maybe someone with such a runtime engine could load http://dev.w3.org/2006/waf/widgets-api/tests/idl-gen/all.html and see if any tests pass? I guess the tests might need to be wrapped up in a widget for that, in which case I have one available at: http://dev.w3.org/2006/waf/widgets-api/tests/idl-gen/idl.wgt (obviously, these tests wouldn’t be enough to test the semantics of the Javascript interface, but hopefully they can serve as a basis for ensuring everyone is using the same interfaces) Side-note: The Widgets Interface spec uses the old AE title in its title element. Dom 1. http://suika.fam.cx/www/webidl2tests/readme
Re: Web Notifications, do we need a new spec?
(adding the Device APIs Working Group mailing list in CC:) Hi John, Web Apps Le lundi 19 octobre 2009 à 14:12 -0700, John Gregg a écrit : Apologies for the delay, I've been spending the majority of my time completing the initial implementation for Chrome, but I've posted a draft version of a spec for notifications to http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification I think that's a good starting point for formalizing it. I think this API would likely fit under the “User Interaction API” http://www.w3.org/2009/05/DeviceAPICharter#deliverables of the Device APIs and Policy Working Group — the group has’t had the time to look in details at the proposed work (but is hoping to do that in a week time), but in the event we would agree that the scope matches our charter, would there be any objection (from Google, from WebApps) in taking up that work in the Device APIs and Policy Working Group rather than WebApps? Thanks, Dom
Re: [widgets] PC: LC#3 and CR#2
Le jeudi 01 octobre 2009 à 06:41 -0400, Arthur Barstow a écrit : Give the July CR says it will not end until November 1, it would seem a bit strange if we published a new LC before then. Actually, the end of CR period really means the document won't go to PR before then - I don't think there would be any problem for the document to go back to LC or to a new CR before that period expires. Dom
[widget-digsig] Test assertions
Hi Marcos, As Kai alluded to in his report [1], we had a chance to look at Widgets Digital Signature last week to see what would be required to create test cases for that specification. As part of that exploratory work, we started two documents similar to the ones that were developed for PC: * a test suite edition of the spec, at: http://dev.w3.org/2006/waf/widgets-digsig/Overview_TSE.html It marks up 17 test assertions for user agents * a test plan document where these test assertions appear, automatically extracted: http://dev.w3.org/2006/waf/widgets-digsig/tests/ We discussed (but haven't documented yet) that the test cases for DigSig would be of two main types: * the ones testing the proper parsing of the signatures files, similar in the work done for config.xml in PC * the ones that focus on the actual hash/signature validation algorithms Kai took an action item [3] to start working on tests cases; that said, as I was the one working on marking up test assertions in the non-official test-suite-edition of DigSig, I noticed that DigSig seems much less testing-ready than PC is (thanks to the huge efforts you've put in the TSE for that spec). For instance, DigSig considers signature files as class of products, where as these aspects would be better considered under either the generic user agent or the conformance checker angle; as a result, many of the MUST in the specs can't easily be linked to a test case in the current state of the spec - I only marked up the 17 ones that were fairly clearly testable. Are you considering putting the same kind of work in DigSig as you did in PC to ease the testing phase? Could you look into the existing 17 assertions as a starting point to see if they reflect realistically the expected behavior of a user agent? Should you start working on a TSE for digSig, it would be great if you could keep the same test assertions ids I've started to use (although given their small number at this time, it wouldn't be a big deal if you choose not to); note that I opted to use two-letters longs ids (e.g. ta-aa, ta-ab), rather than the 8-random-letters-long ones you picked for PC that made up for interesting discussions last week :) [2] Dom 1. http://lists.w3.org/Archives/Public/public-mwts/2009Sep/0009.html 2. http://twitter.com/dontcallmedom/status/4311968310 3. http://www.w3.org/2005/MWI/Tests/track/actions/82
Re: [widgets] Conformance Checker assertions spec
Le mardi 29 septembre 2009 à 18:18 +0200, Marcos Caceres a écrit : Given that the Widget test suite event did not create tests for conformance checker (CC) related assertions, I have moved all conformance checker assertions from the PC Test Suite edition to a new document [1]. FWIW, we chose not to create test assertions for conformance checkers since it seemed to us that the most important and urgent needs were for user agents, rather than conformance checkers. (logically speaking, I don't think this can be taken as a reason for removing the CC test assertions - I think they are both a consequences of conformance checkers interoperability being less important to the market at this stage than UA interop). Thirdly, we don't have anyone committing to implement the assertions, which potentially delays the progression of this specification to Rec. Moving the CC assertions to their own spec allows them to, obviously, be standardized independently. The CC assertions are important and deserve their own specification - they also need to be done properly, with collaboration of implementers. I think this makes sense; I personally think that the conformance checker requirements could probably be published as a note rather than as a rec - since again, the needs for interoperability at that level don't seem all that great just now. I again ask the working group to endorse this move as we move PC to PR. [1] http://dev.w3.org/2006/waf/widgets-pc-cc/Overview.src.html For what it's worth, given that: * PC has been vastly rewritten * test results collection hasn't started (AFAIK) * you're suggesting to remove a bunch of conformance requirements which could be assessed as a substantive change I think it might be worth pushing PC to a short Last Call period (3 weeks), asking to focus only on the changes since CR, and then when the implementation reports are finalized, ask to go to PR directly. HTH, Dom
[WARP] uri attribute is confusing
Hi, The attribute uri on the access element in WARP is somewhat misleading - what it takes is more a URL pattern than a URI. I would suggest renaming it in urlpattern or just pattern (unless there are already many implementations that rely on that attribute name). There may be lessons to be taken in designing these patterns from POWDER http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect the POWDER expressivity needs are much greater than what is needed here. Dom
WebIDL roadmap?
Hello WebApps Working Group, A growing number of groups is relying on WebIDL to define their APIs, including the Device APIs and Policy Working Group (cc'd). As some of the said specs are likely to reach PR in the upcoming months (e.g. Geolocation?), their normative dependence on WebIDL risk to delay their promotion to Rec if WebIDL is still at Working Draft stage. What are the plans for stabilizing WebIDL and pushing it to Rec? The charter has it initially at CR in Q4 2008 - which obviously hasn't happened :) Thanks, Dom
Re: [widgets] Seeking approval of PC Test Suite templates and guide
Hi Marcos, Le jeudi 20 août 2009 à 15:30 +0200, Marcos Caceres a écrit : I've now moved (and updated) all the PC test suite documentation. It can now be found here: http://dev.w3.org/2006/waf/widgets/tests/ It would be great to get the MWTS blessing that we have prepared the documentation, templates, etc. properly before we go forth and create tests. That documents looks very good to me - congrats! I've made minor corrections in-line, but note that the templates directory is missing from the CVS repository, and thus a number of images are not visible in the document. Is anybody going to update the list of test assertions with the existing tests Kai developed? You proposed at some point using an external XML file to keep track of the links between test assertions and test cases: has this been set up yet? Thanks, Dom
Re: [widgets] Test Suite Creation
Le vendredi 31 juillet 2009 à 18:01 +0200, Marcos Caceres a écrit : I've created the first draft of the test suite edition, it is available here (it's ugly on purpose, I will remove the ugly stylesheet soon): http://dev.w3.org/2006/waf/widgets/Overview_TSE.html Includes stable IDs on p's, and HTML-class-based identification of products to which assertions apply: either: product-cc or product-ua Great work, thanks! if you can join the MWTS call today, we can settle on who's going to update the test plan and how - your idea of separating the assertions from the associated metadata sounds good to me. Dom
Re: Widget Test Cases Creation Event - September 21st-23rd, Düsseldorf
Hello all, Le lundi 13 juillet 2009 à 11:57 +0200, Breitschwerdt, Christian, VF-Group a écrit : More information regarding registration, etc to follow shortly via W3C staff/WG chairs. If you are interested in attending that event, please register at: http://www.w3.org/2002/09/wbs/1/widget-test/ The form has indications on the IPR aspect of the event as well. Thanks, Dom
Re: Comments on Widgets spec
Le mercredi 08 juillet 2009 à 15:20 +0200, Marcos Caceres a écrit : I'm mostly satisfied, but see a few comments below. I'm now satisfied, thanks. Dom
Re: Comments on Widgets spec
Le mardi 07 juillet 2009 à 19:53 +0200, Marcos Caceres a écrit : For the sake of the Disposition of Comments, please let us know if you are satisfied with the fixes below (if possible, by the 9th of July). I'm mostly satisfied, but see a few comments below. On Fri, Jun 12, 2009 at 6:35 PM, Dominique Hazael-Massieuxd...@w3.org wrote: Hi, 5.3 Zip Relative Paths has the following bugs: * the ABNF for zip-rel-path uses localized-folder, but only locale-folder is defined Fixed, updated, and simplified. Can you please check the new ABNF? Looks good; checked it with http://www.quut.com/abnfgen/ * the third rule for the conformance checker should be: A CC must inform the author of any Zip relative paths whose length exceed 120 characters (rather than bytes). Fixed. You also removed the rule to inform about relative path whose length exceed 250 bytes - was that on purpose? http://www.w3.org/TR/widgets/#conformance-checker-behavior4 seems to be misplaced under 7.2 instead of 7.3 Fixed. Moved to section 8 (the document sections got reshuffled to make the document easier to read). See: http://dev.w3.org/2006/waf/widgets/#conformance-checker-behavior4 (for sake of the DoC, it was actually moved to section 9.2.1, at http://dev.w3.org/2006/waf/widgets/#conformance-checker- ) There are quite a few aspects that make a zip archive an invalid widget described in the processing section, but which are not highlighted as conformance checker requirements, e.g: * Step 1 labels an archive with a wrong media type as invalid Added to Media Type section: [[ Conformance Checker Behavior A CC MUST inform the author if a widget package is not being served from a remote location with the valid widget media type. ]] * Step 2 adds as cause of invalidity split-zips, and encrypted-zips (beyond the already noted requirements on version and compression method) Added to Invalid Zip Archive section: [[ Conformance Checker Behavior A CC must inform the author that a Zip archive that is split into multiple files or spans multiple volumes, as defined in the [ZIP] specification, is an invalid zip archive. A CC must inform the author that a Zip archive that is encrypted (which is denoted by bit 0 of the general purpose field being set and by the presence of archive decryption header and an archive extra data record, all three of which are defined in the [ZIP] specification), is an invalid zip archive. A CC must inform the author that a Zip archive that contains zero file entries is an invalid zip archive. A CC must inform the author that a Zip archive that contains only folders is an invalid zip archive. ]] * requirements on the configuration file (XML well-formed, vocabulary constraints) (and probably more) Instead of writing conformance checking for every element and attribute, I wrote the following Conformance Checker Behavior: [[ A CC should process a configuration document using the algorithm to process a configuration document. However, where an element or attribute is in error, or invalid, the conformance checker must inform the author. A CC may validate a configuration document against the Relax NG for the configuration document. ]] Looks good, thanks! Dom
RE: [widgets] conformance requirements review
Le dimanche 05 juillet 2009 à 18:50 +0200, Marcin Hanclik a écrit : Just FYI I created a tool to check the BONDI specs under: http://bondi01.obe.access-company.com/ It automatically checks each new release of the BONDI specs directly from the SVN repository. Very nice! Would it be possible to share the source code of these tools, so that both WebApps and DAP participants could re-use and extend them to fit their needs? Dom
Re: [widgets] conformance requirements review
Le mardi 07 juillet 2009 à 20:11 +0200, Marcos Caceres a écrit : Responses inline... As before, for the sake of the Disposition of Comments, please let us know if you are satisfied with the responses below. I'm satisfied, thanks. Dom
Re: An import statement for Web IDL
Le mardi 30 juin 2009 à 06:26 +, Ian Hickson a écrit : However, I do think it'd be nice to have tools to help us check the IDL.. Could we have a tool that just scans the textContent out of pre elements with class=idl, or something? We could give it the URLs of all the specs being developed, and every hour or day or something it could try to fetch all the specs, check that the IDLs still make sense, and if anything bad happens, post an e-mail to some list we all subscribe to. FWIW, I wrote this morning a dead-simple XSLT that does the extraction (in the context of the to-be-chartered Device APIs and Policy WG), and have been looking at widlproc [1] as a way to do XML-based analysis among WebIDLs files; if using XML-stack tools to accomplish the above is acceptable, I could certainly look into setting such a system up. Is there a list of (preferably but not necessarily XHTML) specs from where I could extract the said WebIDLs? What kind of consistency checks should it do? Dom 1. http://widl.webvm.net/svn/widlproc/trunk/doc/widlproc.html
Alpha Widget checker
Hi, Francois Daoust and I played with creating a widget checker tool that implements some of the conformance checker requirements of the widgets PC spec. The said tool can be experimented with at: http://qa-dev.w3.org:8001/widget/ (an uncool URI that is likely to break in the future) but please note that it is not meant to be reliable or useful in any way at this stage - it's more of a proof of concept than anything else. It's built on top of the architecture used for the mobileOK checker, and the code is available at: http://dev.w3.org/cvsweb/2009/widget-checker/ You can get a rough idea of the things the checker already detected by looking at: http://dev.w3.org/2009/widget-checker/src/org/w3c/mwi/widget/xslt/messages.properties.xml It's not clear yet that either Francois or I would be able to spend much more time on that tool; but feedback, suggestions, or interests in contributing to the development of that tool would all be welcome. Dom
[widgets] conformance requirements review
Hi, I wrote a simple XSLT to extract the conformance requirements from the Widgets spec [1], with the following output: http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F% 2Fdev.w3.org%2F2006%2Fwaf%2Fwidgets%2Ftests% 2FextractTestAssertions.xslxmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin% 2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252Fwidgets% 252F Based on these, here is a review of the Widgets spec based on conformance requirements analysis: * ideally, only the classes of products would appear as subjects of the conformance requirements; e.g. A folder may contain zero or more file entries or zero or more folders would be rephrased as A valid widget package may contain folders with zero or more file entries or zero or more folders; this would have two benefits: simplify the analysis of conformance requirements for building test suites, and identify possible ambiguities as to what is affected when the conformance requirements is not respected; that said, I don't think it is crucial so feel free to not go through all the conformance requirements if that's too much work * similarly, conformance requirements that use the passive voice are suspect (since they often don't tell to which class they apply) * For sniffing the content type of images formats, a user agents must use the rule for Identifying the media type of an image - this assumes that the user agent already knows the file it is sniffing is an image; if that's true, the text should make it clear why, and if not, it should probably be reworded to say that a user agent must sniff for images format first * rather than say Reserved file names must be treated as case-sensitive, I would amend the previous sentence to say The reserved file names table, below, contains a *case-sensitive* list... (and similarly for folder names) * If [...] the start file is not one that is supported by a particular user agent, then the CC must inform the author: does that mean that a CC need to know all the supported formats by all user agents? That seems a bit excessive - I guess I can see cases where a conformance checker could be configured to report knowledge on a special user agent, but that would need to be made explicit, and clearly shouldn't be a must * a widget may attempt to access the feature identified by the feature element's name attribute I think the may here is not intended as a conformance requirement, so it probably shouldn't be marked as such * there is a spurious empty em class=ct/em element in A feature canem class=ct/em have zero or more a href=#parameter0 title=parameterparameters/a associated with it. * The steps for processing a widget package involves nine steps that a user agent SHOULD follow ; the should appear in upper case in the source, while other conformance requirements are lower case * a user agent must to decompress is not correct English * If a user agent encounters an unusable file entry, it must ignore the file entry: is ended by a colon, but followed by a new sentence * The algorithm always returns a string, which may be empty: again, this may doesn't look like a conformance requirement so shouldn't be marked as such * that must eventually be presented to the end-user - I don't think this is meant as a conformance requirement (e.g. a conformance checker is a user agent, but will probably never present any of the widget content to the end-user); I would reword it as to be presented to the end user * an error condition can ask the user agent ignore an object I don't think error conditions can ask anything to anyone in general, so I would rephrase it; I think ignore needs a preceding to too. HTH, Dom 1. http://dev.w3.org/2006/waf/widgets/tests/extractTestAssertions.xsl
Comments on Widgets spec
Hi, 5.3 Zip Relative Paths has the following bugs: * the ABNF for zip-rel-path uses localized-folder, but only locale-folder is defined * the third rule for the conformance checker should be: A CC must inform the author of any Zip relative paths whose length exceed 120 characters (rather than bytes). http://www.w3.org/TR/widgets/#conformance-checker-behavior4 seems to be misplaced under 7.2 instead of 7.3 There are quite a few aspects that make a zip archive an invalid widget described in the processing section, but which are not highlighted as conformance checker requirements, e.g: * Step 1 labels an archive with a wrong media type as invalid * Step 2 adds as cause of invalidity split-zips, and encrypted-zips (beyond the already noted requirements on version and compression method) * requirements on the configuration file (XML well-formed, vocabulary constraints) (and probably more) Dom
Next steps on Widgets testing?
Hi Art, Charles, As was discussed during the WebApps WG F2F in Cannes, the Mobile Web Test Suites Working Group (and in particular, Kai Hendry) has started to work on developing test cases for the Widgets Packaging and Configuration specification: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0235.html There are already quite a number of test cases available there (~50), that target well-defined part of the specifications. Could you let our group know whether you think this is going in the right direction, and what the next steps should be on our side? Also, would it be helpful if the tests were moved to the public CVS server? should they sit in 2006/waf/widgets/tests/ if so? Let me know, Dom Mobile Web Test Suites Working Group co-Chair
W3C Workshop on Security for Access to Device APIs - London, December 10-11
[sorry for the cross-posting, please don't reply-to-all] Hello, W3C just announced a call for participation to a Workshop on security for access to device APIs from the Web, in London on December 10-11 2008. http://www.w3.org/2008/security-ws/ A W3C Workshop is an opportunity for any interested parties to interact and exchange ideas on the topics under discussion. W3C Membership is NOT required to participate in a W3C Workshop. This workshop will focus on the *security challenges* involved in allowing Web applications and widgets to access the APIs that allow to control devices features such as cameras, GPS systems, connectivity and battery levels, external applications launch, access to personal data (e.g. calendar or addressbook), etc, not traditionally available from the Web environment. To participate to this workshop, interested parties need to submit a position paper relevant to this topic before *October 30 2008* to [EMAIL PROTECTED] These position papers will be reviewed by the workshop program committee, and will serve as a basis for the agenda of the two days workshop. Submitters will be notified of acceptance of their papers by November 17. A position paper should: * explain your interest in the Workshop * be aligned with the Workshop's stated goals * be 5 to 10 pages long (2000 - 4000 words) * be formatted in (valid) HTML/XHTML, PDF, or plain text Interested parties are invited to inform the workshop organizers that they are planning to submit a position paper by sending as soon as possible an expression of interest to [EMAIL PROTECTED], including the number of persons from their organizations that are planning to attend the workshop. Topics in scope for the workshop include: * Existing frameworks on desktop and mobile platforms to regulate security policies for specific APIs, * Similarities and differences of the security approaches in desktop and mobile platforms, in a browser and in a widgets environment, * Usability of security relevant user interactions; issues and opportunities in the mobile environment, * Safe language and API subsets, and models for application use of such subsets, * Policy based trust delegation mechanisms, * Reducing the attack surface exposed by Web page scripts * Role of authentication of users and applications in securing API access, * Increasing awareness of good security practices for Web applications, * Usability of security and privacy policies The discussions at this workshop are expected to be relevant in particular to the following W3C Working Groups: * Web Applications Working Group * Geolocation Working Group * Ubiquitous Web Applications Working Group * HTML Working Group * Web Security Context Working Group Should you have any question, please contact Dominique Hazael-Massieux [EMAIL PROTECTED]. Regards, Dom
Support for compression in XHR?
Hello WebApps WG, The Mobile Web Best Practices Working Group is interested to know whether XmlHTTPRequest has any actual or planned support for compression - I looked quickly in the specs and issues list, but didn't find anything relevant. Thanks, Dom
Re: Support for compression in XHR?
Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit : HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make use of those, as long as the underlying HTTP implementation supports them. Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? Dom
Re: Support for compression in XHR?
Le mardi 09 septembre 2008 à 17:37 +0200, Anne van Kesteren a écrit : On Tue, 09 Sep 2008 17:29:03 +0200, Dominique Hazael-Massieux [EMAIL PROTECTED] wrote: I'm sure it could, but if one implementation does it and another doesn't, this leads to interoperability problems - hence the usefulness of documenting it in the spec. Or this is there any catchall requirements in the spec that covers it? The specification states that user agents SHOULD set the Accept-Encoding header and also states that encoded content MUST be decoded. But that's only relevant when receiving data, not sending it, isn't it? Dom
