[Bug 16534] New: give me a demo on php pleaseeeeeeeeeeeeeeeee!

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16534

   Summary: give me a demo on php please!
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
give me a demo on php please!

Posted from: 180.168.167.219
User agent: Mozilla/5.0 (Windows NT 6.2; rv:11.0) Gecko/20100101 Firefox/11.0

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: informal survey - on spec philosophy

2012-03-26 Thread Kang-Hao (Kenny) Lu 
(12/03/27 6:30), Glenn Adams wrote:
> On Mon, Mar 26, 2012 at 4:23 PM, Kang-Hao (Kenny) Lu <
> kennyl...@csail.mit.edu> wrote:
> 
>> (12/03/27 5:43), Glenn Adams wrote:
>>> my position is that, unless somewhere it is documented what the
>> convention
>>> "associated with" means, that it is (1) ambiguous, and (2) can be
>>> interpreted in any of the above four ways;
>>
>> This is still lacking context, but in general I agree with you.
>>
> 
> The specific context this came up in is [1].
> 
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299

For this particular example, I sort of agree that a creative UA can make
XMLHttpRequest reuse an existing XMLHttpRequestUpload and still claim
the UA conforming to the current text, although it seems to be too
theoretical to the point that I think we can allow editors to choose
his/her editorial style.

For what it's worth, this is how the HTML spec says about
MesseageChannel and it's associated ports:

  # When the MessageChannel() constructor is called, it must run the
  # following algorithm:
  #
  # 1. Create a new MessagePort object owned by the script's global
  #object, and let port1 be that object.
  #
  # 2. Create a new MessagePort object owned by the script's global
  #object, and let port2 be that object.
  # 3. Entangle the port1 and port2 objects.

Note the "new"s for the ports there, and "Entabgle" links to the steps
that does the association. This is XMLHttpRequest:

  # The XMLHttpRequest() constructor must return a new XMLHttpRequest
  # object.

and a separated

  # Each XMLHttpRequest object also has an associated
  # XMLHttpRequestUpload object.

.

I know people who think the HTML spec is exceedingly verbose, so I am
not sure it's really the best style that should be used everywhere.


Cheers,
Kenny

Re: informal survey - on spec philosophy

2012-03-26 Thread Marcos Caceres 



On Monday, 26 March 2012 at 23:55, Tab Atkins Jr. wrote:

> On Mon, Mar 26, 2012 at 3:52 PM, Glenn Adams  (mailto:gl...@skynav.com)> wrote:
> > On Mon, Mar 26, 2012 at 4:43 PM, Tab Atkins Jr.  > (mailto:jackalm...@gmail.com)>
> > wrote:
> > > On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams  > > (mailto:gl...@skynav.com)> wrote:
> > > > "if it isn't written in the spec, it isn't allowed by the spec"
> > > 
> > > 
> > > 
> > > The statement you quoted is more or less accurate. Behavior that
> > > isn't specced is almost certain to not be interoperable. If the spec
> > > is incomplete or unclear in some aspect, that's a spec bug, not an
> > > opportunity for implementations to make up their own behavior based on
> > > what the engineer thinks is reasonable at the time they're writing the
> > > code.
> > 
> > 
> > 
> > however, that is exactly what implementers do every day... especially those
> > not closely connected with the spec process
> 
> 
> 
> Of course they do. Reality isn't perfect. That doesn't mean it's a good thing.
> 
> That said, I agree with your point that documenting important points,
> even if it's technically not required, is a good thing if there is a
> reasonable possibility of confusion.
> 


I guess it would be best if people just comment directly on the following (to 
cut to the chase):
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299#c3

Re: informal survey - on spec philosophy

2012-03-26 Thread Tab Atkins Jr. 
On Mon, Mar 26, 2012 at 3:52 PM, Glenn Adams  wrote:
> On Mon, Mar 26, 2012 at 4:43 PM, Tab Atkins Jr. 
> wrote:
>> On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams  wrote:
>>> "if it isn't written in the spec, it isn't allowed by the spec"
>>
>> The statement you quoted is more or less accurate.  Behavior that
>> isn't specced is almost certain to not be interoperable.  If the spec
>> is incomplete or unclear in some aspect, that's a spec bug, not an
>> opportunity for implementations to make up their own behavior based on
>> what the engineer thinks is reasonable at the time they're writing the
>> code.
>
> however, that is exactly what implementers do every day... especially those
> not closely connected with the spec process

Of course they do.  Reality isn't perfect.  That doesn't mean it's a good thing.

That said, I agree with your point that documenting important points,
even if it's technically not required, is a good thing if there is a
reasonable possibility of confusion.

~TJ

Re: informal survey - on spec philosophy

2012-03-26 Thread Glenn Adams 
On Mon, Mar 26, 2012 at 4:43 PM, Tab Atkins Jr. wrote:

> On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams  wrote:
> > It has been stated to me that, at least for "open web platform
> standards",
> > the following statement is true and is shared by the majority:
> >
> > "if it isn't written in the spec, it isn't allowed by the spec"
> >
> > I happen to disagree with the truth of this, based on my personal
> experience
> > both with spec writing and with implementation/use of specs, but I would
> be
> > curious to see who agrees with this idea or not.
> >
> > The case in point is an instance of a possible ambiguity in a spec
> because a
> > particular assumption/convention is not documented; i.e., an assumption
> that
> > something isn't allowed even though it isn't explicitly disallowed.
> While I
> > agree it is, in general, impossible (or at least impractical) to document
> > all disallowances, I do believe it is important to document important
> > disallowances, particular when there are concerns raised about spec
> > ambiguity.
>
> The statement you quoted is more or less accurate.  Behavior that
> isn't specced is almost certain to not be interoperable.  If the spec
> is incomplete or unclear in some aspect, that's a spec bug, not an
> opportunity for implementations to make up their own behavior based on
> what the engineer thinks is reasonable at the time they're writing the
> code.
>

however, that is exactly what implementers do every day... especially those
not closely connected with the spec process

Re: informal survey - on spec philosophy

2012-03-26 Thread Tab Atkins Jr. 
On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams  wrote:
> It has been stated to me that, at least for "open web platform standards",
> the following statement is true and is shared by the majority:
>
> "if it isn't written in the spec, it isn't allowed by the spec"
>
> I happen to disagree with the truth of this, based on my personal experience
> both with spec writing and with implementation/use of specs, but I would be
> curious to see who agrees with this idea or not.
>
> The case in point is an instance of a possible ambiguity in a spec because a
> particular assumption/convention is not documented; i.e., an assumption that
> something isn't allowed even though it isn't explicitly disallowed. While I
> agree it is, in general, impossible (or at least impractical) to document
> all disallowances, I do believe it is important to document important
> disallowances, particular when there are concerns raised about spec
> ambiguity.

The statement you quoted is more or less accurate.  Behavior that
isn't specced is almost certain to not be interoperable.  If the spec
is incomplete or unclear in some aspect, that's a spec bug, not an
opportunity for implementations to make up their own behavior based on
what the engineer thinks is reasonable at the time they're writing the
code.

~TJ

Re: informal survey - on spec philosophy

2012-03-26 Thread Glenn Adams 
On Mon, Mar 26, 2012 at 4:23 PM, Kang-Hao (Kenny) Lu <
kennyl...@csail.mit.edu> wrote:

> (12/03/27 5:43), Glenn Adams wrote:
> > my position is that, unless somewhere it is documented what the
> convention
> > "associated with" means, that it is (1) ambiguous, and (2) can be
> > interpreted in any of the above four ways;
>
> This is still lacking context, but in general I agree with you.
>

The specific context this came up in is [1].

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299


> > this also goes to the issue of whether "if it is not documented in the
> spec
> > it is not allowed" applies; my position is that if the spec is ambiguous
> > (allows for multiple reasonable readings), then it is allowed (even
> though
> > that may not have been the author's intent);
>
> Agreed.
>
> (12/03/27 4:40), Glenn Adams wrote:
> > It has been stated to me that, at least for "open web platform
> > standards", the following statement is true and is shared by the
> > majority:
> >
> > "if it isn't written in the spec, it isn't allowed by the spec"
>
> What context was this statement in? For the spec for API A, you can't
> really write a test that asserts the non-existence of API B of course.
>

 A WebApps spec editor made this assertion to me "if it isn't written in
the spec, it isn't allowed by the spec". I did (do) not agree. I wondered
what others think.

The specific context is how to interpret "associated with" and whether it
means one-to-one or not. Since the spec doesn't define "associated with", I
argue that it need not be interpreted as one-to-one. However, the editor
argued that if the spec doesn't say that it can be interpreted as
non-injective (not one-to-one), then this interpretation is not allowed.

Re: informal survey - on spec philosophy

2012-03-26 Thread Marcos Caceres 


On Monday, 26 March 2012 at 22:43, Glenn Adams wrote:

> 
> On Mon, Mar 26, 2012 at 2:46 PM, Marcos Caceres  (mailto:w...@marcosc.com)> wrote:
> > On Monday, 26 March 2012 at 21:40, Glenn Adams wrote:
> 
> there are two issues here: 
> 
> (1) whether the spec is ambiguous or not (permits multiple interpretations), 
> and
> (2) whether there is an unwritten convention (if the spec doesn't say it then 
> it is not allowed) that applies or not
> 
> my position is that ambiguities should be avoided wherever possible and that 
> important conventions should be documented; further, i'm not sure I would 
> agree with a convention of "if the spec doesn't say it then it is not 
> allowed"; or at least, that is the point of this thread, to see what others 
> think... 
I don't know without a concrete example - just show us the actual text that is 
bugging you (I'm sure the Editor of the spec you are referring to won't mind 
the additional eyes!). 

As an editor, if someone emails me and says "hey Marcos, I'm coding/reviewing 
your spec, but I'm having a hard time understanding this bit X." I try to do my 
best to fix the spec (through rephrasing or adding an example, etc.). I think 
that's what editors are supposed to do: make things really clear for their 
intended audience and friends in the WG (i.e., write specs as you would want 
specs written for you).  


-- 
Marcos Caceres
http://datadriven.com.au

Re: informal survey - on spec philosophy

2012-03-26 Thread Kang-Hao (Kenny) Lu 
(12/03/27 5:43), Glenn Adams wrote:
> my position is that, unless somewhere it is documented what the convention
> "associated with" means, that it is (1) ambiguous, and (2) can be
> interpreted in any of the above four ways;

This is still lacking context, but in general I agree with you.

> this also goes to the issue of whether "if it is not documented in the spec
> it is not allowed" applies; my position is that if the spec is ambiguous
> (allows for multiple reasonable readings), then it is allowed (even though
> that may not have been the author's intent);

Agreed.

(12/03/27 4:40), Glenn Adams wrote:
> It has been stated to me that, at least for "open web platform
> standards", the following statement is true and is shared by the
> majority:
>
> "if it isn't written in the spec, it isn't allowed by the spec"

What context was this statement in? For the spec for API A, you can't
really write a test that asserts the non-existence of API B of course.


Cheers,
Kenny

[Bug 16304] DONE != DONE

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16304

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |

--- Comment #2 from Glenn Adams  2012-03-26 22:21:40 UTC ---
>The events are dispatched in the same task that to makes the transition DONE.
>The whole platform works that way.

The point is that some readers may assume "DONE" really means DONE. Since that
isn't the case, it helps (and certainly doesn't hurt) to add a note such as
suggested below.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: informal survey - on spec philosophy

2012-03-26 Thread Glenn Adams 
On Mon, Mar 26, 2012 at 2:46 PM, Marcos Caceres  wrote:
>
>  On Monday, 26 March 2012 at 21:40, Glenn Adams wrote:
>
> > It has been stated to me that, at least for "open web platform
> standards", the following statement is true and is shared by the majority:
> >
> > "if it isn't written in the spec, it isn't allowed by the spec"
> Can you provide some examples of what you mean? This seems a little out of
> the blue?
>

the spec phrase "associated with" can be interpreted as any of the
following relations [1]:

   - injective and surjective (one-to-one and onto)
   - injective and non-surjective (one-to-one but not onto)
   - non-injective and surjective (not one-to-one but onto)
   - non-injective and non-surjective (not one-to-one and not onto)

[1] http://en.wikipedia.org/wiki/Bijection,_injection_and_surjection

it has been claimed that "associated with" means at least injective and
perhaps also surjective, and that since the spec does not say it can be
non-injective, then the last two could not apply;

my position is that, unless somewhere it is documented what the convention
"associated with" means, that it is (1) ambiguous, and (2) can be
interpreted in any of the above four ways;

this also goes to the issue of whether "if it is not documented in the spec
it is not allowed" applies; my position is that if the spec is ambiguous
(allows for multiple reasonable readings), then it is allowed (even though
that may not have been the author's intent);


> >
> > I happen to disagree with the truth of this, based on my personal
> experience both with spec writing and with implementation/use of specs, but
> I would be curious to see who agrees with this idea or not.
> >
> > The case in point is an instance of a possible ambiguity in a spec
> because a particular assumption/convention is not documented;
> Which one?
>

see above


> > i.e., an assumption that something isn't allowed even though it isn't
> explicitly disallowed. While I agree it is, in general, impossible (or at
> least impractical) to document all disallowances, I do believe it is
> important to document important disallowances, particular when there are
> concerns raised about spec ambiguity.
> >
>
>  I guess it's a case by case thing. But generally, if the spec is written
> with a "not in spec, not allowed" state machine, then it would hold.
>

there are two issues here:

(1) whether the spec is ambiguous or not (permits multiple
interpretations), and
(2) whether there is an unwritten convention (if the spec doesn't say it
then it is not allowed) that applies or not

my position is that ambiguities should be avoided wherever possible and
that important conventions should be documented; further, i'm not sure I
would agree with a convention of "if the spec doesn't say it then it is not
allowed"; or at least, that is the point of this thread, to see what others
think...

Re: informal survey - on spec philosophy

2012-03-26 Thread Miles Fidelman 

Glenn Adams wrote:
It has been stated to me that, at least for "open web platform 
standards", the following statement is true and is shared by the 
majority:


"if it isn't written in the spec, it isn't allowed by the spec"

I happen to disagree with the truth of this, based on my personal 
experience both with spec writing and with implementation/use of 
specs, but I would be curious to see who agrees with this idea or not.


The case in point is an instance of a possible ambiguity in a spec 
because a particular assumption/convention is not documented; i.e., an 
assumption that something isn't allowed even though it isn't 
explicitly disallowed. While I agree it is, in general, impossible (or 
at least impractical) to document all disallowances, I do believe it 
is important to document important disallowances, particular when 
there are concerns raised about spec ambiguity.


Is this not the normative language for W3C specs:
"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 (see [RFC2119] 
). However, for 
readability, these words do not appear in all uppercase letters in this 
specification.


Seems to me that if there isn't a "MUST NOT" or "SHALL NOT" or "SHOULD 
NOT" - then the spec. is silent on the matter.  Now, whether that makes 
for good interoperability or not is a function of how clear the spec. 
and associated validation mechanisms are.


And then there's always the "be /strict in what you send/, /loose in 
what you accept/" rule of thumb.


Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: informal survey - on spec philosophy

2012-03-26 Thread Marcos Caceres 



On Monday, 26 March 2012 at 21:40, Glenn Adams wrote:

> It has been stated to me that, at least for "open web platform standards", 
> the following statement is true and is shared by the majority:
> 
> "if it isn't written in the spec, it isn't allowed by the spec"
Can you provide some examples of what you mean? This seems a little out of the 
blue?   
> 
> I happen to disagree with the truth of this, based on my personal experience 
> both with spec writing and with implementation/use of specs, but I would be 
> curious to see who agrees with this idea or not. 
> 
> The case in point is an instance of a possible ambiguity in a spec because a 
> particular assumption/convention is not documented;
Which one?  
> i.e., an assumption that something isn't allowed even though it isn't 
> explicitly disallowed. While I agree it is, in general, impossible (or at 
> least impractical) to document all disallowances, I do believe it is 
> important to document important disallowances, particular when there are 
> concerns raised about spec ambiguity. 
> 

 I guess it's a case by case thing. But generally, if the spec is written with 
a "not in spec, not allowed" state machine, then it would hold. 

-- 
Marcos Caceres
http://datadriven.com.au

Re: [IndexedDB] Synchronous access to object stores

2012-03-26 Thread Jonas Sicking 
On Mon, Mar 26, 2012 at 5:07 AM, João Eiras  wrote:
>
> Hi.
>
> After a open database request, going from the IDBDatabase to the
> IDBObjectStore's properties is synchronous, which means that either all the
> metadata for every object store has to be preloaded, or that the ecmascript
> engine needs to wait (therefore blocking the page) while the request is done
> in the background.
> The first issue raises the question: what if there are 10 000 object stores
> ? Preloading everything is overkill. The second issues raises another
> question: blocking for file IO ?
>
> var r = indexedDb.open('foo');
> r.onsuccess = function(){
>  r.transaction('o').objectStore('o').indexNames;
> }
>
> Supporting this is a trivial implementation detail, but the spec has the
> issue nonetheless.

The idea is to keep all of the index and objectStore meta-data in
memory. Yes, this could potentially mean keeping information about
1 object stores in memory, but that doesn't seem very different
from how the synchronous nature of the Node API could force you to
keep 1 text nodes in memory.

Creating lots of object stores or indexes is generally going to be
very awkward to do for the page, since you can only add/remove object
stores and indexes from withing "versionchange" transactions. So it
seems unlikely that pages will do this a lot (though it will certainly
happen).

/ Jonas

informal survey - on spec philosophy

2012-03-26 Thread Glenn Adams 
It has been stated to me that, at least for "open web platform standards",
the following statement is true and is shared by the majority:

"if it isn't written in the spec, it isn't allowed by the spec"

I happen to disagree with the truth of this, based on my personal
experience both with spec writing and with implementation/use of specs, but
I would be curious to see who agrees with this idea or not.

The case in point is an instance of a possible ambiguity in a spec because
a particular assumption/convention is not documented; i.e., an assumption
that something isn't allowed even though it isn't explicitly disallowed.
While I agree it is, in general, impossible (or at least impractical) to
document all disallowances, I do believe it is important to document
important disallowances, particular when there are concerns raised about
spec ambiguity.

Regards,
Glenn

[Bug 16297] combining multiple author request headers

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16297

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Anne  2012-03-26 20:24:23 UTC ---
I actually had an XXX on fixing this. Thanks for reminding me!
http://dvcs.w3.org/hg/xhr/rev/0746d35a2068

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16299] editorial - inadequate description of upload attribute

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299

Glenn Adams  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16310] editorial - sub-dividing 4.7.7 infrastructure for the send() method

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16310

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Anne  2012-03-26 17:26:05 UTC ---
That seems overkill. All those algorithms already have hyperlinks available.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16304] DONE != DONE

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16304

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Anne  2012-03-26 17:23:19 UTC ---
The events are dispatched in the same task that to makes the transition DONE.
The whole platform works that way.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16301] editorial - ambiguous language

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16301

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  2012-03-26 17:21:41 UTC ---
Interesting, your interpretation of the current text was wrong. Hopefully it's
all clear now: http://dvcs.w3.org/hg/xhr/rev/2ba0be2d31cd Thanks!

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [Bug 15400] New: WebSocket Protocol reference needs updating

2012-03-26 Thread Ian Hickson 
On Mon, 26 Mar 2012, Arthur Barstow wrote:
>
> Ian - Julian contacted me privately about getting this bug fixed. Is 
> this something you could please fix relatively soon?
> 
> Is there something Julian can do to facilitate a fix e.g. create a patch 
> against some source file?

I'll get right on that as soon as it's the most important thing on my todo 
list.

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

[Bug 16299] editorial - inadequate description of upload attribute

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16299

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Anne  2012-03-26 15:55:41 UTC ---
http://dvcs.w3.org/hg/xhr/rev/ba9735a82582

By the way, many thanks for all these reports!

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16298] editorial - inadequate description of timeout attribute

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16298

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  2012-03-26 15:47:03 UTC ---
http://dvcs.w3.org/hg/xhr/rev/2f60eb4d4aa4

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16296] editorial - possible improved language

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16296

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  2012-03-26 15:36:57 UTC ---
http://dvcs.w3.org/hg/xhr/rev/51e8144fcd42

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16293] missing definition - resolve url

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16293

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  2012-03-26 15:34:21 UTC ---
http://dvcs.w3.org/hg/xhr/rev/e448d1ad77fd

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16290] missing definition - globally unique identifier

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16290

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #1 from Anne  2012-03-26 15:31:10 UTC ---
This is defined by RFC 6454 included via reference to the origin concepts from
HTML. Anyone familiar with the origin concept will know what to do.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16291] editorial - s/higher than/greater than/g

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16291

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  2012-03-26 15:32:39 UTC ---
http://dvcs.w3.org/hg/xhr/rev/9a6be3627677

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16289] inconsistent initial state

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16289

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Anne  2012-03-26 15:27:29 UTC ---
This is only done for flags, because it only matters for those.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16288] editorial - change "metadata" to "internal state"

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16288

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  2012-03-26 15:25:10 UTC ---
http://dvcs.w3.org/hg/xhr/rev/677bfd395b58

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 16287] editorial - ambiguous antecedent of 'their values'

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16287

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Anne  2012-03-26 15:22:24 UTC ---
http://dvcs.w3.org/hg/xhr/rev/063520f74003

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: CfC: publish WD of DOM4; deadine April 2

2012-03-26 Thread Charles McCathieNevile 
On Mon, 26 Mar 2012 13:20:26 +0100, Arthur Barstow   
wrote:


Ms2ger would like to publish a new WD of DOM4 and this is a Call for  
Consensus to do so:




Agreement to this proposal: a) indicates support for publishing a new  
WD; and b) does not necessarily indicate support of the contents of the  
WD.


publish please :)

If you have any comments or concerns about this proposal, please send  
them to public-webapps by April 2 at the latest.


Positive response to this CfC is preferred and encouraged and silence  
will be assumed to mean  agreement with the proposal.


-Thanks, ArtB




--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [Bug 15400] New: WebSocket Protocol reference needs updating

2012-03-26 Thread Arthur Barstow 
Ian - Julian contacted me privately about getting this bug fixed. Is 
this something you could please fix relatively soon?


Is there something Julian can do to facilitate a fix e.g. create a patch 
against some source file?


-Thanks, AB

On 1/3/12 7:36 AM, ext bugzi...@jessica.w3.org wrote:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15400

Summary: WebSocket Protocol reference needs updating
  Component: WebSocket API (editor: Ian Hickson)

CfC: publish WD of DOM4; deadine April 2

2012-03-26 Thread Arthur Barstow 
Ms2ger would like to publish a new WD of DOM4 and this is a Call for 
Consensus to do so:




Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please send 
them to public-webapps by April 2 at the latest.


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean  agreement with the proposal.


-Thanks, ArtB

[IndexedDB] Synchronous access to object stores

2012-03-26 Thread João Eiras 


Hi.

After a open database request, going from the IDBDatabase to the  
IDBObjectStore's properties is synchronous, which means that either all  
the metadata for every object store has to be preloaded, or that the  
ecmascript engine needs to wait (therefore blocking the page) while the  
request is done in the background.
The first issue raises the question: what if there are 10 000 object  
stores ? Preloading everything is overkill. The second issues raises  
another question: blocking for file IO ?


var r = indexedDb.open('foo');
r.onsuccess = function(){
  r.transaction('o').objectStore('o').indexNames;
}

Supporting this is a trivial implementation detail, but the spec has the  
issue nonetheless.

[Bug 14404] Version of an IDBDatabase from an aborted version change transaction needs to be specified

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404

Jonas Sicking  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #8 from Jonas Sicking  2012-03-26 11:52:41 UTC ---
Actually, this is still all sorts of wrong.

The text for the individual properties still say that they remain unchanged,
whereas in reality it seemed like we wanted to say that they do change value
when the transaction is aborted.

And step 9.5 of "versionchange transaction steps" still says that the
properties will "remain unchanged".

And it seems very out-of-place to say what the "default values" are when
there's no text to tie in to the default values.

And I believe there was agreement on the list to revert to an empty list,
rather than null, for objectStoreNames.

Sorry guys, but I think this still needs more work :(

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: CfC: test suite for Web Storage CR; deadline April 11

2012-03-26 Thread Arthur Barstow 
After the start of this CfC, Ms2ger announced [1] that he fixed several 
bugs in the Infraware's Web Storage tests [2] and his changes were made 
directly in their submission directory rather that the 'approved' 
directory. Consequently, this CfC is modified as such:


1. The directory of tests to review is the following (and not the 
[approved] directory):




2. The deadline for review is extended one week - to April 11

Note too that Ms2ger reported the following on the *-testsuite list:

[[
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2012Mar/0030.html

One thing that seems to be missing is tests for the getter / setter / 
creator / deleter on the Storage interface (e.g., localStorage["foo"] = 
"bar" or delete sessionStorage["baz"]); another is the security 
requirements.


Apart from that, I think the test suite is pretty complete.
]]

-Thanks, ArtB

[1] 
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2012Mar/0028.html

[2] http://dvcs.w3.org/hg/webapps/rev/ad44919e3519

On 3/21/12 8:50 AM, ext Arthur Barstow wrote:
WebApps' testing group completed a Request for Review [RfR] of the Web 
Storage tests submitted by Infraware and the tests that are now 
considered approved by the testing group have been copied into the 
[approved] directory. As we agreed in WebApps' testing process 
[Testing], this means the approved tests are now ready for WG wide 
review.


Since Web Storage is now in CR [CR], this is a Call for Consensus to 
assess whether these approved tests should be considered sufficient to 
meet the CR's exit criteria [ExitCriteria].


Assuming this CfC passes, my expectation on the next step is that we 
will start the interop phase i.e.  run the tests against 
implementations with the target of exiting CR (per [ExitCriteria]).


If you have any comments or concerns about this CfC, please send them 
to public-webapps@w3.org by April 4 at the latest. Positive response 
is preferred and encouraged and silence will be considered the same as 
agreeing with the proposal.


-Thanks, ArtB

[RfR] 
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2012Mar/0011.html

[approved] http://w3c-test.org/webapps/WebStorage/tests/approved/
[Testing] http://www.w3.org/2008/webapps/wiki/Approval
[CR] http://www.w3.org/TR/2011/CR-webstorage-20111208/
[ExitCriteria] http://www.w3.org/TR/2011/CR-webstorage-20111208/#crec

[Bug 16501] IndexedDB: IDBObjectStore/IDBIndex.keyPath when key path is an Array?

2012-03-26 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16501

Jonas Sicking  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.