Re: RfC: pre-LC version of Screen Orientation; deadline August 18

[Dominique Hazael-Massieux]

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:
> 
>
> 
> 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:
* Promise should be Promise 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

[Dominique Hazael-Massieux]

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

[XHR] XHR 1 / XHR 2

[Dominique Hazael-Massieux]

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

January 2014 edition of Standards for Web Applications on Mobile: current state and roadmap

[Dominique Hazael-Massieux]

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

Re: [clipboard] typo in WebIDL

[Dominique Hazael-Massieux]

Le mardi 08 octobre 2013 à 03:03 -0700, Hallvord R. M. Steen a écrit :
> - Original Message -
> From: "Dominique Hazael-Massieux" 
> 
> > 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.html&output=html

Dom

September 2013 edition of Standards for Web Applications on Mobile: current state and roadmap

[Dominique Hazael-Massieux]

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

Re: [streams-api] WebIDL bug

[Dominique Hazael-Massieux]

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  
> 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

[clipboard] typo in WebIDL

[Dominique Hazael-Massieux]

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

[streams-api] WebIDL bug

[Dominique Hazael-Massieux]

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

Extending createObjectUrl to MediaStream?

[Dominique Hazael-Massieux]

Hi WebApps WG,

The Media Capture Task Force (responsible for specs that deal with
MediaStream objects [1]) has been considering whether one should be able
to assign a MediaStream to  and  elements via an URL
obtained via createObjectURL or not, and is seeking feedback on the
question.

More precisely:
A. we define a new srcObject attribute on HTMLMediaElement objects that
can take directly a MediaStream object and make it playable
  video.srcObject = mediastream;
B. the spec also supports assigning a MediaStream via the src attribute,
via an URL obtained through createObjectURL:
 video.src = URL.createObjectURL(mediastream);

While there are ongoing discussions on how to spec B properly [2] (which
will require coordination with the WebApps Working Group), we are first
and foremost wondering if that option is needed at all.

We are thus looking for input on the use cases for createObjectURL as
used for the File API, and whether these use cases would also apply to
our MediaStream case. In general, is there a need for any object
readable by media elements to support an URL-based approach for
consistency with the rest of the platform?

Thanks!

Dom for capture-ACTION-23

1. http://dev.w3.org/2011/webrtc/editor/getusermedia.html
2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594

June 2013 edition of "Standards for Web Applications on Mobile: current state and roadmap"

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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"

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

Standards for Web applications on mobile devices: May 2012 updates

[Dominique Hazael-Massieux]

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

[IME] WebIDL bugs

[Dominique Hazael-Massieux]

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/

Draft report for offline apps workshop

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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  
>  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) which
> > 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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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)

[Dominique Hazael-Massieux]

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

Re: Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)

[Dominique Hazael-Massieux]

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:  
> 
> 

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;  is the
equivalent to  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

Widgets & ApplicationCache (was: Standards for Web applications on mobile devices: August 2011 updates)

[Dominique Hazael-Massieux]

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

Standards for Web applications on mobile devices: August 2011 updates

[Dominique Hazael-Massieux]

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: Publishing an update of File API spec

[Dominique Hazael-Massieux]

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%2F&input=&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

Re: Battery Status API vs. Geolocation API

[Dominique Hazael-Massieux]

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
> 
> 
> 

Status of URL Interface?

[Dominique Hazael-Massieux]

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-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=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

Re: Overview of W3C technologies for mobile Web applications

[Dominique Hazael-Massieux]

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

Update to Standards for Web applications on mobile

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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%2F&input=&output=html )

HTH,

Dom

Re: Overview of W3C technologies for mobile Web applications

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

RE: Overview of W3C technologies for mobile Web applications

[Dominique Hazael-Massieux]

(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

[Dominique Hazael-Massieux]

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

Overview of W3C technologies for mobile Web applications

[Dominique Hazael-Massieux]

(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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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  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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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: Reminder: RfC: LCWD of Digital Signatures for Widgets; deadline 6 May 2010

[Dominique Hazael-Massieux]

Le jeudi 29 avril 2010 à 18:17 +0200, Marcos Caceres a écrit :
> I have fund a number of issues with the dig sig spec:
> [...]

FWIW, I had found the same types of problems as Marcos when I looked at
the spec back in September to set up the testing framework around it,
and I mentioned back then that I thought the spec would need to be
rewritten as it was done for P&C to make it reasonably testable.

> In the interest of saving time, I have created a new version of the
> spec that addresses all the issues above:
> http://dev.w3.org/2006/waf/widgets-digsig/

I haven't had time to review the new spec yet (and I'm not sure I will
in time before the LC deadline), but I strongly support the goals and
methodology behind the rewrite (probably somewhat unsurprisingly :)

Dom

Re: Server Sent Events vs Web Sockets?

[Dominique Hazael-Massieux]

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?

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

Re: [widgets] Testing infrastructure for Widget Access Request Policy (WARP) spec

[Dominique Hazael-Massieux]

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

[widgets-interface] Marking Widget as [NoInterfaceObject]

[Dominique Hazael-Massieux]

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: A Method for Writing Testable Conformance Clauses and its Applications (Was Re: Write up of test assertion extraction methodology)

[Dominique Hazael-Massieux]

Hi Marcos,

Le mardi 19 janvier 2010 à 16:49 +0100, Marcos Caceres a écrit :
> A draft of "A Method for Writing Testable Conformance Clauses and its 
> Applications" in now available for review online [1]. For those that 
> have not seen it, it basically just documents how we are standardizing 
> the Widget specs and some basic QA processes:
> http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html

Thanks for your thorough edits to the original document!

I’ve brought my own set of corrections [1] to the draft (including the
errors and possible improvements pointed by Doug); the most visible
change I made was to replace “conformance clause” by “conformance
requirement” to be consistent with the usual vocabulary in that space.

Once Wilhelm and Dmitri have sent their reviews (and assuming they don’t
show any blockers), I’ll move with the requesting publication as First
Public Working Group Note.

Dom (for MWI test suites ACTION-114
http://www.w3.org/2005/MWI/Tests/track/actions/114)

1.
http://dev.w3.org/cvsweb/2008/dev-ind-testing/extracting-test-assertions-pub.html.diff?r1=1.27&r2=1.51&f=h

Re: Seeking status of testing Widget Digital Signature spec

[Dominique Hazael-Massieux]

Hi Art et al.,

Le vendredi 18 décembre 2009 à 10:17 -0500, Arthur Barstow a écrit :
> Since MTWS did some work on the test suite [1] for the Widget Digital  
> Signature spec [2], we would appreciate a short summary of your plans  
> for this test suite.
> 
> Please include public-webapps@w3.org in any related response(s).

My understanding is that work on the test suite stopped waiting for the
specification to be re-cast in a more testable language (similar to what
was done for P&C). I thought that was part of the plans of the WebApps
Working Group, but it seems this may have been wishful thinking.

Note that the test suites working group’s charter is expiring at the end
of this month — we are asking for a short 6-weeks extension to finish a
couple of work items, but I don’t expect the group itself will be in a
position to provide much more help for DigSig at this point; I assume
(some of the) group participants might continue to do so, though.

Dom

> [1] http://dev.w3.org/cvsweb/2006/waf/widgets-digsig/tests/
> [2] http://www.w3.org/TR/2009/CR-widgets-digsig-20090625/

[WARP] comment on subdomains

[Dominique Hazael-Massieux]

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.

(kudos on the spec otherwise; I find it to be very crisp)

Dom

1.
http://www.w3.org/mid/4aebcb34-9bf1-4c14-8e54-40e1eee59...@robineko.com

Re: DAP and security (was: Rename "File API" to "FileReader API"?)

[Dominique Hazael-Massieux]

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?

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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”?)

[Dominique Hazael-Massieux]

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

Re: [widgets interface] Tests generated from WebIDL

[Dominique Hazael-Massieux]

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

Re: [widgets interface] Tests generated from WebIDL

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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 A&E title in its
>  element.
> 
> Dom
> 
> 1. http://suika.fam.cx/www/webidl2tests/readme

DAP and security (was: Rename “File API” to “FileReader API”?)

[Dominique Hazael-Massieux]

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: Use Cases and Requirements for Saving Files Securely

[Dominique Hazael-Massieux]

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

Re: CfC: to publish First Public Working Draft of File API spec; deadline Nov 10

[Dominique Hazael-Massieux]

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: Rename “File API” to “FileReader API”?

[Dominique Hazael-Massieux]

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

Rename “File API” to “FileReader API”?

[Dominique Hazael-Massieux]

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: [WARP] IRI normalization only for HTTP*?

[Dominique Hazael-Massieux]

Le lundi 02 novembre 2009 à 21:15 -0800, Dominique Hazael-Massieux a
écrit :
> WARP requires normalization of IRI using ToASCII only for HTTP and HTTPS
> uris — is there any reason for that?

Also, it seems that normalization is only part of the algorithm for
parsing the  element, but is not indicated for the process of
evaluating whether access to a network resource is granted or not. I
think it’s self-evident that this is meant, but it is probably worth
highlighting, if only to make sure it gets tested :)

Dom

[WARP] IRI normalization only for HTTP*?

[Dominique Hazael-Massieux]

Hi,

WARP requires normalization of IRI using ToASCII only for HTTP and HTTPS
uris — is there any reason for that?

Dom

Re: [widgets interface] Tests generated from WebIDL

[Dominique Hazael-Massieux]

Le mercredi 28 octobre 2009 à 22:43 +0100, Dominique Hazael-Massieux a
écrit :
> 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?

Actually, I’ve just remembered that Opera had graciously shared an early
build of the next version of their widgets runtime engine, and running
it on the test widget, I get 15 tests that pass and 13 that fail (17
that couldn’t be run due to the said failures), which make me hopeful
the tests are actually useful.

I’m naturally still interested on feedback on the generated tests.

Dom

[widgets interface] Tests generated from WebIDL

[Dominique Hazael-Massieux]

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 A&E title in its
 element.

Dom

1. http://suika.fam.cx/www/webidl2tests/readme

Re: [FileAPI] Latest Revision of Editor's Draft

[Dominique Hazael-Massieux]

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%2F&output=html
(a missing “;” and an erroneous usage of “attribute” inside an
Exception).

Dom

Re: Web Notifications, do we need a new spec?

[Dominique Hazael-Massieux]

(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] P&C: LC#3 and CR#2

[Dominique Hazael-Massieux]

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

Re: [widgets] Conformance Checker assertions spec

[Dominique Hazael-Massieux]

Le mercredi 30 septembre 2009 à 15:32 +0200, Robin Berjon a écrit :
> Also, does going to LC again re-open an exclusionary period? I think  
> we can't go to Rec (and probably not to PR) until the exclusionary  
> period is over. Dom?

A new LC opens a 2 months exclusion period during which the group is not
supposed to go to PR, indeed; the only way to shorten that period is for
every AC Reps in the WebApps WG to agree to waive their exclusions
rights - which given the size of the group is likely to be a difficult
exercice...

Dom

Re: [widgets] Conformance Checker assertions spec

[Dominique Hazael-Massieux]

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 P&C 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 P&C to PR.
> [1]   http://dev.w3.org/2006/waf/widgets-pc-cc/Overview.src.html

For what it's worth, given that:
 * P&C 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 P&C 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

[widget-digsig] Test assertions

[Dominique Hazael-Massieux]

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 P&C:
 * 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 P&C
 * 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 P&C 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 P&C 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
P&C 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

[WARP] "uri" attribute is confusing

[Dominique Hazael-Massieux]

Hi,

The attribute "uri" on the  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?

[Dominique Hazael-Massieux]

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 P&C Test Suite templates and guide

[Dominique Hazael-Massieux]

Hi Marcos,

Le jeudi 20 août 2009 à 15:30 +0200, Marcos Caceres a écrit :
> I've now moved (and updated) all the P&C 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

[Dominique Hazael-Massieux]

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 '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

WebIDL checker

[Dominique Hazael-Massieux]

(bcc to public-html, public-webapps, public-device-apis)

Hello,

I have just released a simple on-line WebIDL checker:
http://www.w3.org/2009/07/webidl-check
It detects bugs in the WebIDLs it finds inside HTML documents - it looks
for  elements with a class set to "idl" or "webidl", and then
validates what it extracts using Aplix' widlproc:
http://widl.webvm.net/svn/widlproc/trunk/doc/widlproc.html

See it for instance:
 * applied to HTML5: http://www.w3.org/2009/07/webidl-check?doc=http%3A%
2F%2Fdev.w3.org%2Fhtml5%2Fspec%2FOverview.html
 * to Geolocation: http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F
%2Fwww.w3.org%2FTR%2F2009%2FWD-geolocation-API-20090707%2F

More details on my blog:
http://people.w3.org/~dom/archives/2009/07/webidl-checker/

I'm open for suggestions of improvements - in particular if having a
other output formats in addition to the HTML report would be useful.

Hope this useful to some,

Dom

RE: [widgets] conformance requirements review

[Dominique Hazael-Massieux]

Le lundi 13 juillet 2009 à 13:38 +0200, Marcin Hanclik a écrit :
> I cannot publish the source code now, also due to the immaturity of the tool.

I personally wouldn't mind that immaturity and would be happy to
contribute in making it more mature.

> The tool was developed to fit the format used within BONDI, it does not 
> understand the HTML format used in W3C (HTML is the output, input is WebIDL + 
> doxygen).

It's fairly straightforward to extract the WebIDLs from W3C specs (e.g.
using XSLT), and I can also imagining annotating these with doxygen
comments by more auto-extracting work.

Thanks,

Dom

Re: Widget Test Cases Creation Event -> September 21st-23rd, Düsseldorf

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

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-Massieux 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

[Dominique Hazael-Massieux]

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: [widgets] conformance requirements review

[Dominique Hazael-Massieux]

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: An import statement for Web IDL

[Dominique Hazael-Massieux]

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  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

[Dominique Hazael-Massieux]

Hi,

Francois Daoust and I played with creating a widget checker tool that
implements some of the conformance checker requirements of the widgets
P&C 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

[Dominique Hazael-Massieux]

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.xsl&xmlfile=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  element in "A feature
   can have zero or more parameters 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 

Re: Comments on Widgets spec

[Dominique Hazael-Massieux]

Hi,

I have also noted that the two examples in 7.2 use a wrong namespace
(w3.org instead of www.w3.org).

Dom

Comments on Widgets spec

[Dominique Hazael-Massieux]

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

Re: Next steps on Widgets testing?

[Dominique Hazael-Massieux]

Hi,

Le jeudi 04 décembre 2008 à 15:17 -0500, Arthur Barstow a écrit :
> Today, during the Widgets voice conf, we briefly discussed the  
> location you proposed and we agreed with your proposal.

The tests have now been imported to the WAF CVS space:
http://dev.w3.org/cvsweb/2006/waf/widgets/tests/

Regards,

Dom

Next steps on Widgets testing?

[Dominique Hazael-Massieux]

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

[Dominique Hazael-Massieux]

[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

Re: Support for compression in XHR?

[Dominique Hazael-Massieux]

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

Re: Support for compression in XHR?

[Dominique Hazael-Massieux]

Le mardi 09 septembre 2008 à 16:10 +0100, Geoffrey Sneddon a écrit :
> > 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?
> 
> Why can it not just be added transparently by the XHR implementation?

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?

Dom

Re: Support for compression in XHR?

[Dominique Hazael-Massieux]

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