Manu Sporny | 2 Jun 05:47 2010

Re: JSON-LD - Universal Linked Data markup for Web Services

On 05/31/2010 06:40 AM, Robin Berjon wrote:
> I don't want to speak for this WG, and I'd rather we looked more
> closely at technology before thinking about publication. I think we
> ought to point out that rechartering WebApps isn't the easiest thing
> ever, so that adding deliverables might prove tricky no matter what.

Understandable... never hurts to ask. :)

> - This is an interesting project, but I don't think that you want to
> set out with the goal of producing a replacement for SOAP. 

Sorry, didn't mean to make it seem like it was a complete replacement
for SOAP. JSON-LD, combined with a number of other design patterns that
are starting to become standard on the web, could do something similar
to what SOAP was and is used for today.

> You want
> your goal to be something like the exchange of semantically rich
> information using JSON that addresses the needs of a large segment of
> the Web community. If it helps bring SOAP to the horrible death it so
> dearly deserves, fine, but that's a side-effect.


> - Your approach is built on the idea of encoding RDF or RDF-like
> models into JSON. That has the downside of requiring people who
> already have and use JSON-based exchange systems to change their
> data. 

Actually, it doesn't require developers to change their data. At least,
(Continue reading)

Arthur Barstow | 2 Jun 13:10 2010

Reminder: Seeking comments on LCWDs of Server-events, Web Storage, Web Workers; deadline 30-June-2010

Hixie - would you please provide a short status and plan for these docs?

-Thanks, Art Barstow

-------- Original Message --------
Subject: 	Seeking comments on LCWDs of Server-events, Web Storage, Web 
Workers; deadline 30-June-2010
Date: 	Tue, 22 Dec 2009 18:37:20 +0100
From: 	Arthur Barstow <art.barstow <at>>
To: 	public-webapps <public-webapps <at>>

On December 22 WebApps published the following Last Call Working
Drafts (LCWD):

1. Server-Sent Events

2. Web Storage

3. Web Workers

The deadline for comments is 30 June 2010 and the list for comments is:

   public-webapps <at>

-Art Barstow

(Continue reading)

Florian Stegmaier | 2 Jun 13:40 2010

Automatic translation/validation of WebIDL documents

Dear Doug, all,

i am participating the W3C Media Annotations Working Group [1] and co- 
edit the API for Resource 1.0 document [2]. Since we are going to LC  
soon, we want to initiate implementing the API specified. The main  
intention is, that we translate the WebIDL specification of the API  
automatically by the use of a WebIDL parser. Yet, we have identified  
the "esidl" parser [3], which is able to perform the transformation of  
WebIDL descriptions into method stubs (e.g., C++ or Java). We tried to  
translate our API, but translation errors occurd (e.g., because of  
array definitions). I found a mailing list entry about a discussion  
[4] regarding WebIDL and Arrays - maybe the translation error is  
somehow linked with this problem?

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?

Thanks in advance!

Best regards,

  (LC version)
(Continue reading)

Ian Hickson | 2 Jun 13:57 2010

Re: Reminder: Seeking comments on LCWDs of Server-events, Web Storage, Web Workers; deadline 30-June-2010

On Wed, 2 Jun 2010, Arthur Barstow wrote:
> Hixie - would you please provide a short status and plan for these docs?
> 1. Server-Sent Events
> 2. Web Storage
> 3. Web Workers

I hope to have CR drafts for the above specifications ready in July, 
assuming no further feedback is received. If further feedback is received, 
it may take a bit longer. Subsequently, I expect to receive implementation 
feedback resulting in changes over the next few years, in conjunction with 
the creation of thorough test suites for these drafts, culminating in a PR 
in a decade or so once two bug-free widely-available non-experimental 
implementations of each draft exist (as determined by the test suites).


Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Dominique Hazael-Massieux | 2 Jun 14:25 2010

Re: Automatic translation/validation of WebIDL documents

Le mercredi 02 juin 2010 à 13:40 +0200, Florian Stegmaier a écrit :
> My overall question is, if you have any experience with WebIDL parser,  
> or perhaps could point me to a project, which is most up-to-date to  
> the current version of the WebIDL specification? I have also tried to  
> validate our API spec using the validator of [5], but i am not quiet  
> sure if this validator is able to handle the array definitions. Do you  
> know also a validator, to make sure if our spec is correct?

My understanding is that the WebIDL spec still needs to be updated to
reflect the addition of arrays (i.e. no change in that regard since

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:


> [1]
> [2] 
>   (LC version)
> [3]
> [4]
> [5]

Cristiano Sumariva | 1 Jun 17:18 2010

HTML5 File

I have been reading the specification on file section.

I would like to ask why not propose that File interface allow a create method to let user save data for his use?


Interface File extends Blob
    attribute unsigned long long currentPosition;
    readonly attribute signed long long deviceSpaceLeft;
    readonly attribute unsigned short machineEndian;
    const unsigned short BIG_ENDIAN = 1;
    const unsigned short LITTLE_ENDIAN = 0;
    const unsigned short UNKNOW_SIZE = -1;
    File create( );
    File createBynary();
    signed long write( in DOMString text, optional in unsigned long long position,  optional DOMString fromCharset )
    signed long writeBinary( in DOMString blob, optional in unsgined long long position )

An web application in this way could for example create a list of computed values and allow the user to save the contents to a file without need send data for the server to pack contents and issue a file download request to client.
Or implement an image editor in javascript code using the new canvas element and allow read, create, store to be done without server assistance. Work on offline mode too.

About security on file creation:
When the web application request this operation File.create() the browser could launch a confirm( save file) dialog so the user only could grant the rights for a file creation.
This dialog( modal? ) would manage file overwrite and more stuff related to file access( user may write at selected folder ) so that returned file reference could be overwritten by client script without trouble.
The return type for that function could be string or a File object.
An empty name value or Exception signal that user denied the request.

If there is concerns about absolute file paths been exposed to javascript code
then the File.create method could return a boolean status indicating that the object is ready to write( true ) and no file paths would be exposed at all. Or only the basename of file without path information.

For differences between binary and text modes a second method call could signal File object that the new file should be used on binary mode:
File.createBinary() - same behavior like File.create above but in binary mode.

The file object could have some read only properties for device space control:
For example:
readonly File.deviceSpaceLeft  - so when script is making write calls to file if would know in advance if space still available for writing. Or application could launch a warn that no space left to save data. If the implementer do not know how to tell the space left then a File.UNKNOWSIZE value should be returned.

double File.currentPosition - traditional File pointer to know where in the file the client is writing to. Since size is readonly changing this property move the current position in file cursor. Negative values are invalid and ignored. A positive value greater then current value increase the file size to the new size( doing this at begin could be a way to reserve space needed on disk at once since the file would grow to this current size, and help filesystem reduce fragmentation ). Changing this attribute on a file opened for read does nothing and is ignored. The size atrribute should reflect the new size confirming that file size increased.

May cause UI hangs on large move requests.
User agents may show on the create dialog a max file size allowed to be created making impossible to script consume all space left on device.

readonly boolean File.machineEndian - binary files on target machine could have data stored in different formats then the script reading would expect. This flag would tell the script how to pack unpack data to be used on client machine.


Arthur Barstow | 2 Jun 15:10 2010

[widgets] Draft agenda for 3 June 2010 voice conf

Below is the draft agenda for the June 3 Widgets Voice Conference (VC).

Inputs and discussion before the VC on all of the agenda topics 
via public-webapps is encouraged (as it can result in a shortened 
meeting). Please address Open/Raised Issues and Open Actions before the 

Minutes from the last VC:

-Regards, Art Barstow


1. Review and tweak agenda

2. Announcements

3. Digital Signature spec

a. LC comment period ended June 1 (no comments submitted); proposal to 
publish Candidate Recommendation

4. Packaging and Configuration spec

a. Comments from I18N WG:

  comment 21: i18n string

  comment 22: Default content

  comment 23: i18n string

  comment 21: Language tag case

b. Comments from Addison Phillips:

c. Publishing Proposed Recommendation

5. View Modes Media Feature spec

a. Comments from Jim Allan

6. AOB

a. Continue discussion from May 27 re GZip, streaming and widget packaging:


  Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 
Boston; 06:00 Seattle
  Duration: 90 minutes max
  Zakim Bridge:+1.617.761.6200, + or +44.117.370.6152
  PIN: 9231 ("WAF1");
  IRC: channel = #wam; irc:// ;
  Confidentiality of minutes: Public

Arthur Barstow | 2 Jun 15:07 2010

Re: comments

On 5/28/10 2:15 PM, ext Marcos Caceres wrote:
> On Fri, May 28, 2010 at 4:52 PM, Robin Berjon<robin <at>>  wrote:
>> Hi Jim,
>> your comments reach us right after the WG decided to take the specification to CR, but thankfully I was a
bit slow with the editing so that we could take them into account :)
>> On May 27, 2010, at 22:42 , Jim Allan wrote:
>>> View-mode: fullscreen. It is not clear whether fullscreen includes a full
>>> set of chrome, or includes no chrome.  You mention 'chrome' in the
>>> 'windowed' and 'floating' viewmodes. For consistency, chrome presence should
>>> be noted in fullscreen.
>> That's correct, I've now clarified this by adding a mention of chrome for both fullscreen and maximized.
>>> It should be noted that the User Agent Accessibility Guidelines 2.0 [1] has
>>> success criteria that allow the user to override author settings for a
>>> variety of viewport view-modes including the inclusion/exclusion of
>>> 'chrome.'
>> Yes, and that's fine. The idea here is that the UA would make a best effort at matching the intent in a way
that makes sense rather than be ultra strict. For instance, if the app goes fullscreen but keeps a teeny bit
of chrome (at user option or not) to make it easier to exit fullscreen, then matching the view-mode:
fullscreen media query is quite clearly the right thing to do.
>>> Please consider including a statement such as
>>> "The user agent *must* display the view-modes in a manner that meets the
>>> accessibility guidelines of UAAG20. "
>> As much as I'd like more UAs to support UAAG I don't think that this requirement is appropriate here. The VM
specification defines a technology with a single purpose: "if the window in which the content is being
rendered is like this, then apply these CSS style rules". It does *not* define how a UA ought to display an
actual set of window states, it doesn't in fact even require UAs to support all the view modes. I'd expect
that an application running on an iPhone would only support maximized and fullscreen — if it applied
different style rules for each, it would still be 100% conformant.
> FWIW, I agree with Robin here.
I also agree with Robin and Marcos.

Jim, WAI UA community - please let us know (as soon as possible) whether 
or not Robin's response and edits adequately address your comments.

-Regards, Art Barstow

Jeremy Orlow | 2 Jun 15:39 2010

Re: [IndexedDB] [Bug 9562] New: Opening a database with a different description is underspecified

On Mon, May 24, 2010 at 9:41 PM, Shawn Wilsher <sdwilsh <at>> wrote:
On 4/20/2010 11:46 AM, bugzilla <at> wrote:
The spec is unspecified as to what we should do when a database is opened with
a different description than it was previously opened. I'd assume we'd want to
update the description.
Does anybody else have thoughts on what the right behavior should be here?

Probably just overrite with the latest version of the description?  As such, it might make sense to make it optional.
bugzilla | 2 Jun 16:01 2010

[Bug 9698] Rename all instances of noOverwrite to overwite

Jeremy Orlow <jorlow <at>> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
                 CC|                            |jorlow <at>
         Resolution|                            |DUPLICATE

--- Comment #1 from Jeremy Orlow <jorlow <at>>  2010-06-02 14:01:23 ---

*** This bug has been marked as a duplicate of bug 9769 ***


Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.