Re: Obsolescence notices on old specifications, again

[Bjoern Hoehrmann]

* Glenn Adams wrote:
>That doesn't really work for me. What would work for me is something like:
>
>"Although DOM Level 2 continues to be subject to Errata
>Management,
>it is no longer being actively maintained. Content authors and implementers
>are encouraged to consider the use of newer formulations of the Document
>Object Model, including DOM4 , which is
>currently in process for Advancing a Technical Report to
>Recommendation
>."

The point is to say something along the lines of "If this document
contains errors, or text that is often misunderstood, do not expect
corrections or clarifications to appear here or in the associated
errata document, you are more likely to find them $elsewhere". The
W3C Process requires Working Groups to keep the errata document up
to date and to keep their Recommendations up do date by applying
errata to the Recommendations and publishing them through the PER
process. That is "Errata Management" as far as I would understand
the term, and the Working Group wishes to convey they won't do so.

The document would be "subject to Errata Management" only in so far
as that publishing such a note would not remove the option for the
Working Group to change its mind, but that is not useful information
for people the note would be addressed to: if the group did change
its mind, it can just update the note, new readers would get up to
date information, and people who read the note long ago would require
a note at $elsewhere to learn about new developments at the old lo-
cation. That the Working Group might change its mind they would al-
ready know due to the note being there in the first place.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Jonas Sicking]

On Tue, Jan 24, 2012 at 5:28 PM, Joshua Bell  wrote:
>
>
> On Tue, Jan 24, 2012 at 5:15 PM, Jonas Sicking  wrote:
>>
>> On Tue, Jan 24, 2012 at 4:23 PM, Joshua Bell  wrote:
>> >
>> >
>> > On Tue, Jan 24, 2012 at 4:16 PM, Israel Hilerio 
>> > wrote:
>> >>
>> >> On Tuesday, January 24, 2012 11:38 AM, Jonas Sicking wrote:>
>> >> > Based on this (pending details from microsoft of course) I suggest
>> >> > the
>> >> > following set of steps:
>> >> >
>> >> > 1. If /keyPath/ is the empty string, skip the remaining steps and
>> >> > /value/ is not
>> >> > modified.
>> >> > 2. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/.
>> >> > 3. if /object/ is not an Object object or an Array object (see
>> >> > structured clone
>> >> > algorithm), then throw a DOMException of type DataError.
>> >> > 4. If /remainingKeypath/ has a period in it, assign
>> >> > /remainingKeypath/
>> >> > to be
>> >> > everything after the first period and assign /attribute/ to be
>> >> > everything
>> >> > before that first period. Otherwise, go to step 8.
>> >> > 5. If /object/ does not have an attribute named /attribute/, then
>> >> > create
>> >> > the
>> >> > attribute and assign it an empty object.
>> >> > 6. Assign /object/ to be the value of the attribute named /attribute/
>> >> > on
>> >> > /object/.
>> >> > 7. Go to step 3.
>> >> > 8. NOTE: The steps leading here ensure that /remainingKeyPath/ is a
>> >> > single
>> >> > attribute name (i.e. string without periods) by this step. They also
>> >> > ensure
>> >> > that /object/ is an Object or an Array, and not a Date, RegExp, Blob
>> >> > etc.
>> >> > 9. Let /attribute/ be /remainingKeyPath/ 10. Set an attribute named
>> >> > /attribute/ on /object/ with the value /key/.
>> >> >
>> >> > Note that the intent is that these steps are only executed if
>> >> > evaluating
>> >> > the
>> >> > keyPath did not yield a value. I.e. if we know that we need to modify
>> >> > the
>> >> > stored value. Because of this we know that at step
>> >> > 10 the object does not have an attribute with name /attribute/.
>> >> >
>> >> > Let me know if these steps sound ok?
>> >> >
>> >> > / Jonas
>> >> >
>> >>
>> >> The steps look good to me.
>> >>
>> >> Israel
>> >>
>> >
>> > Ditto.
>>
>> Sweet! Though as I was copying these steps into the bug I realized
>> that step 1 is superfluous as I already pointed out earlier in this
>> thread (this is disregarding what we decide regarding empty-string as
>> valid keyPaths for objectStores and/or indexes).
>>
>> I hope it was ok that I removed that step as I copied the steps into the
>> bug.
>
>
> If we decide to keep empty-string as a valid keyPath, it would not hurt to
> leave an informative note at the start of the section describing this
> algorithm pointing out that keyPath is guaranteed not be empty based on the
> preconditions for autoIncrement.

Good point. We should also point out that step 9 will never result in
a property being overwritten.

/ Jonas

Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

[Jonas Sicking]

On Tue, Jan 24, 2012 at 2:42 PM, Israel Hilerio  wrote:
> On Tuesday, January 24, 2012 2:15 PM, Jonas Sicking wrote:
>> On Tue, Jan 24, 2012 at 12:48 PM, Jonas Sicking  wrote:
>> > On Tue, Jan 24, 2012 at 12:33 PM, Israel Hilerio 
>> wrote:
>> >> On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote:
>> >>> On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio
>> >>> 
>> >>> wrote:
>> >>> >> >> In addition, the index method in IDBObjectStore uses
>> >>> >> >> InvalidStateError to convey two different meanings: the object
>> >>> >> >> has been removed or deleted and the transaction being used
>> finished.
>> >>> >> >> It seems that it would be better to separate these into:
>> >>> >> >> * InvalidStateError when the source object has been removed or
>> >>> deleted.
>> >>> >> >> * TransactionInactiveError when the transaction being used is
>> inactive.
>> >>> >> >>
>> >>> >> >> What do you think?  I can open a bug if we agree this is the
>> >>> >> >> desired behavior.
>> >>> >> >
>> >>> >> >
>> >>> >> > Did this come out of the discussion here:
>> >>> >> >
>> >>> >> > http://lists.w3.org/Archives/Public/public-
>> webapps/2011OctDec/1589.
>> >>> >> > htm
>> >>> >> > l
>> >>> >> >
>> >>> >> > If so, the rationale for which exception type to use is
>> >>> >> > included, although no-one on the thread was deeply averse to the
>> alternative.
>> >>> >> > If it's a different issue can give a more specific example?
>> >>> >>
>> >>> >> Right. I think InvalidStateErr is better, for the reason detailed
>> >>> >> in the above referenced email.
>> >>> >>
>> >>> >> I agree we're using the same exception for two error conditions,
>> >>> >> but I'm not terribly worried that this will make debugging harder for
>> authors.
>> >>> >>
>> >>> >> But I don't feel strongly so if there's a good reason I'm ok with
>> >>> >> changing things.
>> >>> >>
>> >>> >> / Jonas
>> >>> >>
>> >>> >
>> >>> > I agree that InvalidStateErr makes sense here.  The issue we're
>> >>> > presenting is
>> >>> the use of one exception for two error conditions.
>> >>> > We just want to remove the ambiguity and cleanup of the language.
>> >>> > We
>> >>> have this issue in the IDBObjectStore.index and
>> >>> IDBTransaction.objectStore methods.
>> >>> >
>> >>> > One alternative could be to just leave "InvalidStateError" and
>> >>> > remove the
>> >>> "or" clause from the description.
>> >>> > That would leave us with:
>> >>> >
>> >>> > 1. InvalidStateError - Occurs if a request is made on a source
>> >>> > object that
>> >>> has been deleted or removed.
>> >>> >
>> >>> > Alternatively, we could add one more exception to capture the "or"
>> clause:
>> >>> >
>> >>> > 2. TransactionInactiveError - Occurs if the transaction the object
>> >>> > store
>> >>> belongs to has finished.
>> >>> >
>> >>> > I'm okay with only doing #1, if you all agree.  This simplifies
>> >>> > things and
>> >>> captures the idea stated in the reference email.  Let me know what you
>> think.
>> >>>
>> >>> Hmm.. I think I'm not fully following you. Did you intend for #1 to
>> >>> change normative behavior, or to be an editorial clarification?
>> >>>
>> >>> Simply removing the part after the "or" seems to result in a
>> >>> normative change since nowhere would we say that an exception should
>> >>> be thrown if
>> >>> index() is called after a transaction has finished. I.e. removing it
>> >>> would mean that index() would have to return an IDBIndex instance
>> >>> even when called after the transaction has finished.
>> >>>
>> >>> Maybe the solution is to change the text to something like: "Thrown
>> >>> if the function is called on a source object that has been deleted.
>> >>> Also thrown if the transaction the object store belongs to has finished."
>> >>>
>> >>> / Jonas
>> >>
>> >> Sorry for the confusion.  My assumption for #1 was that it would be
>> >> okay not to throw an exception if a developer were to make a call to
>> >> IDBObjectStore.index and IDBTransaction.objectStore when there is no
>> transaction as long as any requests from those objects would throw
>> TransactionInactiveError.
>> >> This would leave TransactionInactiveError to be thrown by methods that
>> return IDBRequests only.
>> >>
>> >> In Alternative #2, we were proposing to add TransactionInactiveError
>> >> to the exception list to avoid the exception overloading.  It just seems
>> weird to overload InvalidStateError with multiple definitions.
>> >>
>> >> Should we just do #2, then?
>> >
>> > Hmm.. the throwing for index() when called was after the transaction
>> > was ended was done on request from you guys as I recall it.
>> >
>> > As mentioned in the discussion at [1] I think that
>> > TransactionInactiveError is the wrong exception to throw here.
>> >
>> > l really don't understand the problem of throwing the same exception
>> > for two different error conditions. For example IDBObjectStore.put and
>> > IDBObjectStore.add throws a DataError for 7 different error conditions
>> > as enumerated in the bullet list

Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Joshua Bell]

On Tue, Jan 24, 2012 at 5:15 PM, Jonas Sicking  wrote:

> On Tue, Jan 24, 2012 at 4:23 PM, Joshua Bell  wrote:
> >
> >
> > On Tue, Jan 24, 2012 at 4:16 PM, Israel Hilerio 
> > wrote:
> >>
> >> On Tuesday, January 24, 2012 11:38 AM, Jonas Sicking wrote:>
> >> > Based on this (pending details from microsoft of course) I suggest the
> >> > following set of steps:
> >> >
> >> > 1. If /keyPath/ is the empty string, skip the remaining steps and
> >> > /value/ is not
> >> > modified.
> >> > 2. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/.
> >> > 3. if /object/ is not an Object object or an Array object (see
> >> > structured clone
> >> > algorithm), then throw a DOMException of type DataError.
> >> > 4. If /remainingKeypath/ has a period in it, assign /remainingKeypath/
> >> > to be
> >> > everything after the first period and assign /attribute/ to be
> >> > everything
> >> > before that first period. Otherwise, go to step 8.
> >> > 5. If /object/ does not have an attribute named /attribute/, then
> create
> >> > the
> >> > attribute and assign it an empty object.
> >> > 6. Assign /object/ to be the value of the attribute named /attribute/
> on
> >> > /object/.
> >> > 7. Go to step 3.
> >> > 8. NOTE: The steps leading here ensure that /remainingKeyPath/ is a
> >> > single
> >> > attribute name (i.e. string without periods) by this step. They also
> >> > ensure
> >> > that /object/ is an Object or an Array, and not a Date, RegExp, Blob
> >> > etc.
> >> > 9. Let /attribute/ be /remainingKeyPath/ 10. Set an attribute named
> >> > /attribute/ on /object/ with the value /key/.
> >> >
> >> > Note that the intent is that these steps are only executed if
> evaluating
> >> > the
> >> > keyPath did not yield a value. I.e. if we know that we need to modify
> >> > the
> >> > stored value. Because of this we know that at step
> >> > 10 the object does not have an attribute with name /attribute/.
> >> >
> >> > Let me know if these steps sound ok?
> >> >
> >> > / Jonas
> >> >
> >>
> >> The steps look good to me.
> >>
> >> Israel
> >>
> >
> > Ditto.
>
> Sweet! Though as I was copying these steps into the bug I realized
> that step 1 is superfluous as I already pointed out earlier in this
> thread (this is disregarding what we decide regarding empty-string as
> valid keyPaths for objectStores and/or indexes).
>
> I hope it was ok that I removed that step as I copied the steps into the
> bug.


If we decide to keep empty-string as a valid keyPath, it would not hurt to
leave an informative note at the start of the section describing this
algorithm pointing out that keyPath is guaranteed not be empty based on the
preconditions for autoIncrement.

Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Jonas Sicking]

On Tue, Jan 24, 2012 at 4:23 PM, Joshua Bell  wrote:
>
>
> On Tue, Jan 24, 2012 at 4:16 PM, Israel Hilerio 
> wrote:
>>
>> On Tuesday, January 24, 2012 11:38 AM, Jonas Sicking wrote:>
>> > Based on this (pending details from microsoft of course) I suggest the
>> > following set of steps:
>> >
>> > 1. If /keyPath/ is the empty string, skip the remaining steps and
>> > /value/ is not
>> > modified.
>> > 2. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/.
>> > 3. if /object/ is not an Object object or an Array object (see
>> > structured clone
>> > algorithm), then throw a DOMException of type DataError.
>> > 4. If /remainingKeypath/ has a period in it, assign /remainingKeypath/
>> > to be
>> > everything after the first period and assign /attribute/ to be
>> > everything
>> > before that first period. Otherwise, go to step 8.
>> > 5. If /object/ does not have an attribute named /attribute/, then create
>> > the
>> > attribute and assign it an empty object.
>> > 6. Assign /object/ to be the value of the attribute named /attribute/ on
>> > /object/.
>> > 7. Go to step 3.
>> > 8. NOTE: The steps leading here ensure that /remainingKeyPath/ is a
>> > single
>> > attribute name (i.e. string without periods) by this step. They also
>> > ensure
>> > that /object/ is an Object or an Array, and not a Date, RegExp, Blob
>> > etc.
>> > 9. Let /attribute/ be /remainingKeyPath/ 10. Set an attribute named
>> > /attribute/ on /object/ with the value /key/.
>> >
>> > Note that the intent is that these steps are only executed if evaluating
>> > the
>> > keyPath did not yield a value. I.e. if we know that we need to modify
>> > the
>> > stored value. Because of this we know that at step
>> > 10 the object does not have an attribute with name /attribute/.
>> >
>> > Let me know if these steps sound ok?
>> >
>> > / Jonas
>> >
>>
>> The steps look good to me.
>>
>> Israel
>>
>
> Ditto.

Sweet! Though as I was copying these steps into the bug I realized
that step 1 is superfluous as I already pointed out earlier in this
thread (this is disregarding what we decide regarding empty-string as
valid keyPaths for objectStores and/or indexes).

I hope it was ok that I removed that step as I copied the steps into the bug.

/ Jonas

Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Joshua Bell]

On Tue, Jan 24, 2012 at 4:16 PM, Israel Hilerio wrote:

> On Tuesday, January 24, 2012 11:38 AM, Jonas Sicking wrote:>
> > Based on this (pending details from microsoft of course) I suggest the
> > following set of steps:
> >
> > 1. If /keyPath/ is the empty string, skip the remaining steps and
> /value/ is not
> > modified.
> > 2. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/.
> > 3. if /object/ is not an Object object or an Array object (see
> structured clone
> > algorithm), then throw a DOMException of type DataError.
> > 4. If /remainingKeypath/ has a period in it, assign /remainingKeypath/
> to be
> > everything after the first period and assign /attribute/ to be everything
> > before that first period. Otherwise, go to step 8.
> > 5. If /object/ does not have an attribute named /attribute/, then create
> the
> > attribute and assign it an empty object.
> > 6. Assign /object/ to be the value of the attribute named /attribute/ on
> > /object/.
> > 7. Go to step 3.
> > 8. NOTE: The steps leading here ensure that /remainingKeyPath/ is a
> single
> > attribute name (i.e. string without periods) by this step. They also
> ensure
> > that /object/ is an Object or an Array, and not a Date, RegExp, Blob etc.
> > 9. Let /attribute/ be /remainingKeyPath/ 10. Set an attribute named
> > /attribute/ on /object/ with the value /key/.
> >
> > Note that the intent is that these steps are only executed if evaluating
> the
> > keyPath did not yield a value. I.e. if we know that we need to modify the
> > stored value. Because of this we know that at step
> > 10 the object does not have an attribute with name /attribute/.
> >
> > Let me know if these steps sound ok?
> >
> > / Jonas
> >
>
> The steps look good to me.
>
> Israel
>
>
Ditto.

RE: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Israel Hilerio]

On Tuesday, January 24, 2012 11:38 AM, Jonas Sicking wrote:
> On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell  wrote:
> > On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking  wrote:
> >>
> >> On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell 
> wrote:
> >> > There's another edge case here - what happens on a put (etc)
> >> > request to an object store with a key generator when the object
> >> > store's key path does not yield a value, yet the algorithm below
> >> > exits without changing the value.
> >> >
> >> > Sample:
> >> >
> >> > store = db.createObjectStore("my-store", {keyPath: "a.b",
> autoIncrement:
> >> > true});
> >> > request = store.put("value");
> >> >
> >> > 3.2.5 for "put" has this error case "The object store uses in-line
> >> > keys and the result of evaluating the object store's key path
> >> > yields a value and that value is not a valid key." resulting in a
> >> > DataError.
> >>
> >> The intent here was for something like:
> >>
> >> store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement:
> >> true});
> >> request = store.put({ a: { b: { hello: "world" } });
> >>
> >> In this case "4.7 Steps for extracting a key from a value using a key
> >> path" will return the { hello: "world" } object which is not a valid
> >> key and hence a DataError is thrown.
> >>
> >> > In this case, "4.7
> >> > Steps for extracting a key from a value using a key path" says "no
> >> > value is returned", so that error case doesn't apply.
> >>
> >> Yes, in your example that error is not applicable.
> >>
> >> > "5.1 Object Store Storage Operation" step 2 is: "If store uses a
> >> > key generator and key is undefined, set key to the next generated
> >> > key. If store also uses in-line keys, then set the property in
> >> > value pointed to by store's key path to the new value for key."
> >> >
> >> > Per the algorithm below, the value would not change. (Another
> >> > example would be a keyPath of "length" and putting [1,2,3])
> >> >
> >
> >
> > Although it's unimportant to the discussion below, I realized after
> > the fact that my Array/length example was lousy since |length| is of
> > course assignable.
> 
> Just to be perfectly clear and avoid any misunderstanding, the same thing
> happens for non-assignable properties. For example:
> 
> store1 = db.createObjectStore("store1", { keyPath: "a.length",
> autoIncrement: true});
> store1.put({ a: "str" }); // stores an entry with key 3
> store2 = db.createObjectStore("store2", { keyPath: "a.size",
> autoIncrement: true});
> store2.put({ a: my10KbBlob }); // stores an entry with key 10240
> 
> >> So, with that in mind we still need to figure out the various edge
> >> cases and write a detailed set of steps for modifying a value using a
> >> keyPath. In all these examples i'll assume that the key 1 is
> >> generated. I've included the Firefox behavior in all cases, not
> >> because I think it's obviously correct, but as a data point. I'm
> >> curious to hear what you guys do too.
> >>
> >> What happens if a there are missing objects "higher up" in the keyPath:
> >> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement:
> >> true }); store.put({ x: "str" }); Here there is nowhere to directly
> >> store the new value since there is no "a" property.
> >> What we do in Firefox is to insert objects as needed. In this case
> >> we'd modify the value such that we get the following:
> >> { x: "str", a: { b: { c: 1 } } }
> >> Same thing goes if part of the "object chain" is there:
> >> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement:
> >> true }); store.put({ x: "str", a: {} }); Here Firefox will again
> >> store { x: "str", a: { b: { c: 1 } } }
> >>
> >
> > Per this thread/bug, I've landed a patch in Chromium to follow this
> > behavior. Should be in Chrome Canary already and show up in 18.
> 
> Cool.

IE follows the same behavior as FF.

> 
> >> What happens if a value "higher up" in the keyPath is not an object:
> >> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement:
> >> true }); store.put({ a: "str" }); Here there not only is nowhere to
> >> directly store the new value. We also can't simply insert the missing
> >> objects since we can't add a "b"
> >> property to the value "str". Exact same scenario appears if you
> >> replace "str" with a 1 or null.
> >> What we do in Firefox is to throw a DataError exception.
> >> Another example of this is simply
> >> store = db.createObjectStore("os", { keyPath: "a", autoIncrement:
> >> true }); store.put("str");
> >
> > Chrome currently defers setting the new value until the transaction
> > executes the asynchronous request, and thus doesn't raise an exception
> > but fails the request. I agree that doing this at the time of the call
> > makes more sense and is more consistent and predictable. If there's
> > consensus here I'll file a bug against Chromium.
> 
> Awesome!
> 

IE follows the same behavior as FF.

> >> What happens if a value "higher up" in the keyPath is a host

Re: CfC: to add Speech API to Charter; deadline January 24

[Glen Shires]

Art, Charles,
We are very pleased to see the positive responses to the CfC.

In particular, we believe this meets all the criteria that Art suggested in
[1].

1. Relatively clear scope of the feature(s)
The scope is well-defined and bounded. [1] [2]

2. Editor commitment(s)
Google and Nuance have committed to serve as editors, and we welcome
additional editors. [3] [4]

3. Implementation commitments from at least two WG members
Google and Microsoft plan implementations, and Mozilla has shown strong
interest. [5] [6]
In addition, Nuance plans an implementation of the "network speech
services" to support the user-agent. [4]

4. Testing commitment(s)
Google will provide a test suite, and we welcome additional
contributors. [3]


What is the next step for adding this to the charter"?


[1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0065.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0235.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0074.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0113.html
[5] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0281.html
[6] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0067.html

Bjorn Bringert
Satish Sampath
Glen Shires


On Tue, Jan 24, 2012 at 9:49 AM, Adrian Bateman wrote:

> Microsoft is open to adding this to the WebApps charter.
>
> We certainly want to see work on a speech API for user agents proceed at
> W3C. Our priorities for the API are 1) a procedural (JavaScript) API and 2)
> a declarative syntax for speech recognition and text-to-speech in HTML. We
> think WebApps would be a good venue to bring speech to the attention of
> members who wouldn't normally participate in this area. On the other hand
> we recognise that there may be some members who are interested in moving
> speech forward but who might not be willing to make IPR commitments for
> other specifications that WebApps works on. If that is the case then we'd
> rather have them involved in a separate working group than not benefit from
> their contributions.
>
> Cheers,
>
> Adrian.
>
> On Friday, January 20, 2012 12:58 PM, Arthur Barstow wrote:
> > The deadline for comments is extended to January *24*.
> >
> > On 1/20/12 6:55 AM, ext Arthur Barstow wrote:
> > > The deadline for comments is extended to January.
> > >
> > > Andrian, Maciej - I would appreciate it you would please provide some
> > > feedback on this CfC.
> > >
> > > On 1/12/12 7:31 AM, ext Arthur Barstow wrote:
> > >> Glen Shires and some others at Google proposed [1] that WebApps add
> > >> Speech API to WebApps' charter and they put forward the Speech
> > >> Javascript API Specification [2] as as a starting point. Members of
> > >> Mozilla and Nuance have voiced various levels of support for this
> > >> proposal. As such, this is a Call for Consensus to add Speech API to
> > >> WebApps' charter.
> > >>
> > >> Positive response to this CfC is preferred and encouraged and silence
> > >> will be considered as agreeing with the proposal. The deadline for
> > >> comments is January 19 and all comments should be sent to
> > >> public-webapps at w3.org.
> > >>
> > >> -AB
> > >>
> > >> [1]
> > >> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.ht
> > >> ml
> > >> [2]
> > >> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-169
> > >> 6/speechapi.html
> > >>
> > >
>
>
>
>

Re: IndexedDB: Extra properties in optionalParameters objects

[Cameron McCormack]

Joshua Bell:

By my reading of the IDB and WebIDL specs, the optionalParameters
parameter is a WebIDL dictionary
(http://www.w3.org/TR/IndexedDB/#options-object-concept). The ECMAScript
binding algorithm for WebIDL dictionaries
(http://www.w3.org/TR/WebIDL/#es-dictionary) is such that the members
expected in the IDL dictionary are read out of the ECMAScript object,
but the properties of the ECMAScript object itself are never enumerated
and therefore "extra" properties should be ignored. Therefore, the
"parameter" property in the test code would be ignored, and this would
be treated the same as db.createObjectStore(name, {}) which should not
produce an error.


That's right.

Re: IndexedDB: Extra properties in optionalParameters objects

[Jonas Sicking]

On Tue, Jan 24, 2012 at 2:36 PM, Joshua Bell  wrote:
> I noticed a test regarding optional parameters
> on http://samples.msdn.microsoft.com/ietestcenter/#indexeddb that IE10PP4
> and Chrome 15 are marked as failing and Firefox 8 is marked as passing. (I
> have Chrome 18 and FF9 handy - no changes.)
>
> The specific test is "IDBDatabase.createObjectStore() - attempt to create an
> object store with an invalid optional parameter"
> at http://samples.msdn.microsoft.com/ietestcenter/indexeddb/indexeddb_harness.htm?url=idbdatabase_createObjectStore7.htm and
> the actual JavaScript code that's being tested:
>
> objStore = db.createObjectStore(objectStoreName, { parameter: 0 });
>
>
> By my reading of the IDB and WebIDL specs, the optionalParameters parameter
> is a WebIDL dictionary
> (http://www.w3.org/TR/IndexedDB/#options-object-concept). The ECMAScript
> binding algorithm for WebIDL dictionaries
> (http://www.w3.org/TR/WebIDL/#es-dictionary) is such that the members
> expected in the IDL dictionary are read out of the ECMAScript object, but
> the properties of the ECMAScript object itself are never enumerated and
> therefore "extra" properties should be ignored. Therefore, the "parameter"
> property in the test code would be ignored, and this would be treated the
> same as db.createObjectStore(name, {}) which should not produce an error.
>
> So I would consider the IE10 and Chrome behavior correct, and the test
> itself and Firefox behavior incorrect.
>
> Thoughts?

Yup. We made this change in the spec a while ago (I was the one who
was pushing for the throwing behavior, but eventually gave in). The
change was made by switching to using WebIDL dictionaries which behave
exactly as you describe.

This has also been fixed in newer versions of Firefox. This is fixed
in Firefox 10 which will be released very soon (a week or two).

/ Jonas

RE: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

[Israel Hilerio]

On Tuesday, January 24, 2012 2:15 PM, Jonas Sicking wrote:
> On Tue, Jan 24, 2012 at 12:48 PM, Jonas Sicking  wrote:
> > On Tue, Jan 24, 2012 at 12:33 PM, Israel Hilerio 
> wrote:
> >> On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote:
> >>> On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio
> >>> 
> >>> wrote:
> >>> >> >> In addition, the index method in IDBObjectStore uses
> >>> >> >> InvalidStateError to convey two different meanings: the object
> >>> >> >> has been removed or deleted and the transaction being used
> finished.
> >>> >> >> It seems that it would be better to separate these into:
> >>> >> >> * InvalidStateError when the source object has been removed or
> >>> deleted.
> >>> >> >> * TransactionInactiveError when the transaction being used is
> inactive.
> >>> >> >>
> >>> >> >> What do you think?  I can open a bug if we agree this is the
> >>> >> >> desired behavior.
> >>> >> >
> >>> >> >
> >>> >> > Did this come out of the discussion here:
> >>> >> >
> >>> >> > http://lists.w3.org/Archives/Public/public-
> webapps/2011OctDec/1589.
> >>> >> > htm
> >>> >> > l
> >>> >> >
> >>> >> > If so, the rationale for which exception type to use is
> >>> >> > included, although no-one on the thread was deeply averse to the
> alternative.
> >>> >> > If it's a different issue can give a more specific example?
> >>> >>
> >>> >> Right. I think InvalidStateErr is better, for the reason detailed
> >>> >> in the above referenced email.
> >>> >>
> >>> >> I agree we're using the same exception for two error conditions,
> >>> >> but I'm not terribly worried that this will make debugging harder for
> authors.
> >>> >>
> >>> >> But I don't feel strongly so if there's a good reason I'm ok with
> >>> >> changing things.
> >>> >>
> >>> >> / Jonas
> >>> >>
> >>> >
> >>> > I agree that InvalidStateErr makes sense here.  The issue we're
> >>> > presenting is
> >>> the use of one exception for two error conditions.
> >>> > We just want to remove the ambiguity and cleanup of the language.
> >>> > We
> >>> have this issue in the IDBObjectStore.index and
> >>> IDBTransaction.objectStore methods.
> >>> >
> >>> > One alternative could be to just leave "InvalidStateError" and
> >>> > remove the
> >>> "or" clause from the description.
> >>> > That would leave us with:
> >>> >
> >>> > 1. InvalidStateError - Occurs if a request is made on a source
> >>> > object that
> >>> has been deleted or removed.
> >>> >
> >>> > Alternatively, we could add one more exception to capture the "or"
> clause:
> >>> >
> >>> > 2. TransactionInactiveError - Occurs if the transaction the object
> >>> > store
> >>> belongs to has finished.
> >>> >
> >>> > I'm okay with only doing #1, if you all agree.  This simplifies
> >>> > things and
> >>> captures the idea stated in the reference email.  Let me know what you
> think.
> >>>
> >>> Hmm.. I think I'm not fully following you. Did you intend for #1 to
> >>> change normative behavior, or to be an editorial clarification?
> >>>
> >>> Simply removing the part after the "or" seems to result in a
> >>> normative change since nowhere would we say that an exception should
> >>> be thrown if
> >>> index() is called after a transaction has finished. I.e. removing it
> >>> would mean that index() would have to return an IDBIndex instance
> >>> even when called after the transaction has finished.
> >>>
> >>> Maybe the solution is to change the text to something like: "Thrown
> >>> if the function is called on a source object that has been deleted.
> >>> Also thrown if the transaction the object store belongs to has finished."
> >>>
> >>> / Jonas
> >>
> >> Sorry for the confusion.  My assumption for #1 was that it would be
> >> okay not to throw an exception if a developer were to make a call to
> >> IDBObjectStore.index and IDBTransaction.objectStore when there is no
> transaction as long as any requests from those objects would throw
> TransactionInactiveError.
> >> This would leave TransactionInactiveError to be thrown by methods that
> return IDBRequests only.
> >>
> >> In Alternative #2, we were proposing to add TransactionInactiveError
> >> to the exception list to avoid the exception overloading.  It just seems
> weird to overload InvalidStateError with multiple definitions.
> >>
> >> Should we just do #2, then?
> >
> > Hmm.. the throwing for index() when called was after the transaction
> > was ended was done on request from you guys as I recall it.
> >
> > As mentioned in the discussion at [1] I think that
> > TransactionInactiveError is the wrong exception to throw here.
> >
> > l really don't understand the problem of throwing the same exception
> > for two different error conditions. For example IDBObjectStore.put and
> > IDBObjectStore.add throws a DataError for 7 different error conditions
> > as enumerated in the bullet list at [2]. And IDBCursor.update throws
> > InvalidStateError under two different conditions [3]. And any function
> > which uses structured clones throw DataCloneError for two

IndexedDB: Extra properties in optionalParameters objects

[Joshua Bell]

I noticed a test regarding optional parameters on
http://samples.msdn.microsoft.com/ietestcenter/#indexeddb that IE10PP4 and
Chrome 15 are marked as failing and Firefox 8 is marked as passing. (I have
Chrome 18 and FF9 handy - no changes.)

The specific test is "IDBDatabase.createObjectStore() - attempt to create
an object store with an invalid optional parameter" at
http://samples.msdn.microsoft.com/ietestcenter/indexeddb/indexeddb_harness.htm?url=idbdatabase_createObjectStore7.htm
and
the actual JavaScript code that's being tested:

objStore = db.createObjectStore(objectStoreName, { parameter: 0 });


By my reading of the IDB and WebIDL specs, the optionalParameters parameter
is a WebIDL dictionary (
http://www.w3.org/TR/IndexedDB/#options-object-concept). The ECMAScript
binding algorithm for WebIDL dictionaries (
http://www.w3.org/TR/WebIDL/#es-dictionary) is such that the members
expected in the IDL dictionary are read out of the ECMAScript object, but
the properties of the ECMAScript object itself are never enumerated and
therefore "extra" properties should be ignored. Therefore, the "parameter"
property in the test code would be ignored, and this would be treated the
same as db.createObjectStore(name, {}) which should not produce an error.

So I would consider the IE10 and Chrome behavior correct, and the test
itself and Firefox behavior incorrect.

Thoughts?

Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

[Jonas Sicking]

On Tue, Jan 24, 2012 at 12:48 PM, Jonas Sicking  wrote:
> On Tue, Jan 24, 2012 at 12:33 PM, Israel Hilerio  
> wrote:
>> On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote:
>>> On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio 
>>> wrote:
>>> >> >> In addition, the index method in IDBObjectStore uses
>>> >> >> InvalidStateError to convey two different meanings: the object has
>>> >> >> been removed or deleted and the transaction being used finished.
>>> >> >> It seems that it would be better to separate these into:
>>> >> >> * InvalidStateError when the source object has been removed or
>>> deleted.
>>> >> >> * TransactionInactiveError when the transaction being used is 
>>> >> >> inactive.
>>> >> >>
>>> >> >> What do you think?  I can open a bug if we agree this is the
>>> >> >> desired behavior.
>>> >> >
>>> >> >
>>> >> > Did this come out of the discussion here:
>>> >> >
>>> >> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.
>>> >> > htm
>>> >> > l
>>> >> >
>>> >> > If so, the rationale for which exception type to use is included,
>>> >> > although no-one on the thread was deeply averse to the alternative.
>>> >> > If it's a different issue can give a more specific example?
>>> >>
>>> >> Right. I think InvalidStateErr is better, for the reason detailed in
>>> >> the above referenced email.
>>> >>
>>> >> I agree we're using the same exception for two error conditions, but
>>> >> I'm not terribly worried that this will make debugging harder for 
>>> >> authors.
>>> >>
>>> >> But I don't feel strongly so if there's a good reason I'm ok with
>>> >> changing things.
>>> >>
>>> >> / Jonas
>>> >>
>>> >
>>> > I agree that InvalidStateErr makes sense here.  The issue we're 
>>> > presenting is
>>> the use of one exception for two error conditions.
>>> > We just want to remove the ambiguity and cleanup of the language.  We
>>> have this issue in the IDBObjectStore.index and IDBTransaction.objectStore
>>> methods.
>>> >
>>> > One alternative could be to just leave "InvalidStateError" and remove the
>>> "or" clause from the description.
>>> > That would leave us with:
>>> >
>>> > 1. InvalidStateError - Occurs if a request is made on a source object that
>>> has been deleted or removed.
>>> >
>>> > Alternatively, we could add one more exception to capture the "or" clause:
>>> >
>>> > 2. TransactionInactiveError - Occurs if the transaction the object store
>>> belongs to has finished.
>>> >
>>> > I'm okay with only doing #1, if you all agree.  This simplifies things and
>>> captures the idea stated in the reference email.  Let me know what you 
>>> think.
>>>
>>> Hmm.. I think I'm not fully following you. Did you intend for #1 to change
>>> normative behavior, or to be an editorial clarification?
>>>
>>> Simply removing the part after the "or" seems to result in a normative
>>> change since nowhere would we say that an exception should be thrown if
>>> index() is called after a transaction has finished. I.e. removing it would 
>>> mean
>>> that index() would have to return an IDBIndex instance even when called
>>> after the transaction has finished.
>>>
>>> Maybe the solution is to change the text to something like: "Thrown if the
>>> function is called on a source object that has been deleted. Also thrown if 
>>> the
>>> transaction the object store belongs to has finished."
>>>
>>> / Jonas
>>
>> Sorry for the confusion.  My assumption for #1 was that it would be okay not 
>> to throw an exception
>> if a developer were to make a call to IDBObjectStore.index and 
>> IDBTransaction.objectStore when
>> there is no transaction as long as any requests from those objects would 
>> throw TransactionInactiveError.
>> This would leave TransactionInactiveError to be thrown by methods that 
>> return IDBRequests only.
>>
>> In Alternative #2, we were proposing to add TransactionInactiveError to the 
>> exception list to avoid the
>> exception overloading.  It just seems weird to overload InvalidStateError 
>> with multiple definitions.
>>
>> Should we just do #2, then?
>
> Hmm.. the throwing for index() when called was after the transaction
> was ended was done on request from you guys as I recall it.
>
> As mentioned in the discussion at [1] I think that
> TransactionInactiveError is the wrong exception to throw here.
>
> l really don't understand the problem of throwing the same exception
> for two different error conditions. For example IDBObjectStore.put and
> IDBObjectStore.add throws a DataError for 7 different error conditions
> as enumerated in the bullet list at [2]. And IDBCursor.update throws
> InvalidStateError under two different conditions [3]. And any function
> which uses structured clones throw DataCloneError for two related but
> different error conditions [4].
>
> So I don't see why we couldn't simply keep things as they are now?
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.html
> [2] 
> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#wid

[Bug 15699] My phone does nt save when i download

[bugzilla]

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

Tab Atkins Jr.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jackalm...@gmail.com
 Resolution||INVALID

--- Comment #1 from Tab Atkins Jr.  2012-01-24 21:42:14 
UTC ---
Sounds like a personal problem.

-- 
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 15699] New: My phone does nt save when i download

[bugzilla]

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

   Summary: My phone does nt save when i download
   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: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


Specification: http://www.w3.org/TR/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
My phone does nt save when i download

Posted from: 141.0.8.66
User agent: Opera/9.80 (J2ME/MIDP; Opera Mini/4.4.27779/26.1395; U; en)
Presto/2.8.119 Version/10.54

-- 
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: to add Speech API to Charter; deadline January 24

[Dan Burnett]

On Jan 24, 2012, at 7:50 AM, Dan Burnett wrote:

> 
> On Jan 23, 2012, at 12:39 PM, Arthur Barstow wrote:
> 
>> On 1/23/12 12:17 PM, ext Charles McCathieNevile wrote:
>>> On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires  wrote:
>>> 
 2. WebApps provides a balanced web-centric view for new JavaScript APIs.
 The XG group consisted of a large number of speech experts, but only a few 
 with broad web API expertise. We believe the formation of a new WG
 would have a similar imbalance,
>>> 
>>> I'm not sure this is necessarily the case, and the reverse possibility, 
>>> that the Web Apps group would not have enough speech experts should also be 
>>> considered a potential risk.
>>> 
 whereas the WebApps WG can provide valuable, balanced guidance and
 feedback.
>>> 
>>> (FWIW I don't have a strong opinion on whether this is likely to be a real 
>>> problem as opposed to a risk, and I think this conversation helps us work 
>>> that out).
>> 
>> Another way to help us get the broadest set of stakeholders possible is for 
>> the Speech work to be done in a new WG or an existing WG like with some 
>> speech experts (Voice Browser WG or MMI WG?) and then to create some type of 
>> joint task force with WebApps.
>> 
>> This would have the advantage that WebApps members would only have to make 
>> an IP commitment for the specs created by the task force (and none of the 
>> other WG's specs) and the other WG would not have to make an IP commitment 
>> for any of WebApps' other specs. (Note we are already doing this for the Web 
>> Intents spec and the Dev-API WG).
>> 
>> Is the VBWG or MMIWG interested in taking the lead on the speech spec?
> 
> We will discuss this in today's VBWG call.  As VBWG chair, I am a bit nervous 
> about a joint deliverable.  They are extremely tricky to work out and have 
> the disadvantage that a delay in either group delays overall progress.  
> However, dedicated workers can overcome most of these problems.
> Personally, I agree with Debbie that a separate, dedicated Working Group has 
> the double advantages of clear focus and easier IP commitments.
> 
> -- dan
> (Speaking as both individual and VBWG chair in this email)

The Voice Browser Working Group met earlier today and discussed the possibility 
of taking on the work of continuing the development and standardization of the 
JavaScript API and markup bindings, either individually or in conjunction with 
WebApps.

The following two concerns were raised:
1) The Voice Browser Working Group is a member-confidential group with a large 
membership, so it is possible that gaining IP commitments for doing this work 
may be non-trivial.  The Working Group has had multiple Patent Advisory Groups 
in its lifetime due to its work in both the telephony and automatic speech 
recognition spaces.
2) Based on past experience, there is a strong likelihood that one or more 
browser vendors will not be willing to participate in joint work with the Voice 
Browser Working Group.

The consensus of those on today's call was that the Voice Browser Working Group 
would be willing to pursue leading this effort, but that for the reasons 
mentioned above the VBWG would prefer that the work be done either in a new 
Working Group or in the WebApps WG.

-- Dan Burnett
(speaking as VBWG chair)

Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

[Jonas Sicking]

On Tue, Jan 24, 2012 at 12:33 PM, Israel Hilerio  wrote:
> On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote:
>> On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio 
>> wrote:
>> >> >> In addition, the index method in IDBObjectStore uses
>> >> >> InvalidStateError to convey two different meanings: the object has
>> >> >> been removed or deleted and the transaction being used finished.
>> >> >> It seems that it would be better to separate these into:
>> >> >> * InvalidStateError when the source object has been removed or
>> deleted.
>> >> >> * TransactionInactiveError when the transaction being used is inactive.
>> >> >>
>> >> >> What do you think?  I can open a bug if we agree this is the
>> >> >> desired behavior.
>> >> >
>> >> >
>> >> > Did this come out of the discussion here:
>> >> >
>> >> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.
>> >> > htm
>> >> > l
>> >> >
>> >> > If so, the rationale for which exception type to use is included,
>> >> > although no-one on the thread was deeply averse to the alternative.
>> >> > If it's a different issue can give a more specific example?
>> >>
>> >> Right. I think InvalidStateErr is better, for the reason detailed in
>> >> the above referenced email.
>> >>
>> >> I agree we're using the same exception for two error conditions, but
>> >> I'm not terribly worried that this will make debugging harder for authors.
>> >>
>> >> But I don't feel strongly so if there's a good reason I'm ok with
>> >> changing things.
>> >>
>> >> / Jonas
>> >>
>> >
>> > I agree that InvalidStateErr makes sense here.  The issue we're presenting 
>> > is
>> the use of one exception for two error conditions.
>> > We just want to remove the ambiguity and cleanup of the language.  We
>> have this issue in the IDBObjectStore.index and IDBTransaction.objectStore
>> methods.
>> >
>> > One alternative could be to just leave "InvalidStateError" and remove the
>> "or" clause from the description.
>> > That would leave us with:
>> >
>> > 1. InvalidStateError - Occurs if a request is made on a source object that
>> has been deleted or removed.
>> >
>> > Alternatively, we could add one more exception to capture the "or" clause:
>> >
>> > 2. TransactionInactiveError - Occurs if the transaction the object store
>> belongs to has finished.
>> >
>> > I'm okay with only doing #1, if you all agree.  This simplifies things and
>> captures the idea stated in the reference email.  Let me know what you think.
>>
>> Hmm.. I think I'm not fully following you. Did you intend for #1 to change
>> normative behavior, or to be an editorial clarification?
>>
>> Simply removing the part after the "or" seems to result in a normative
>> change since nowhere would we say that an exception should be thrown if
>> index() is called after a transaction has finished. I.e. removing it would 
>> mean
>> that index() would have to return an IDBIndex instance even when called
>> after the transaction has finished.
>>
>> Maybe the solution is to change the text to something like: "Thrown if the
>> function is called on a source object that has been deleted. Also thrown if 
>> the
>> transaction the object store belongs to has finished."
>>
>> / Jonas
>
> Sorry for the confusion.  My assumption for #1 was that it would be okay not 
> to throw an exception
> if a developer were to make a call to IDBObjectStore.index and 
> IDBTransaction.objectStore when
> there is no transaction as long as any requests from those objects would 
> throw TransactionInactiveError.
> This would leave TransactionInactiveError to be thrown by methods that return 
> IDBRequests only.
>
> In Alternative #2, we were proposing to add TransactionInactiveError to the 
> exception list to avoid the
> exception overloading.  It just seems weird to overload InvalidStateError 
> with multiple definitions.
>
> Should we just do #2, then?

Hmm.. the throwing for index() when called was after the transaction
was ended was done on request from you guys as I recall it.

As mentioned in the discussion at [1] I think that
TransactionInactiveError is the wrong exception to throw here.

l really don't understand the problem of throwing the same exception
for two different error conditions. For example IDBObjectStore.put and
IDBObjectStore.add throws a DataError for 7 different error conditions
as enumerated in the bullet list at [2]. And IDBCursor.update throws
InvalidStateError under two different conditions [3]. And any function
which uses structured clones throw DataCloneError for two related but
different error conditions [4].

So I don't see why we couldn't simply keep things as they are now?

[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.html
[2] 
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBObjectStore-put-IDBRequest-any-value-any-key
[3] 
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBCursor-update-IDBRequest-any-value
[4] http://dev.w3.org/html5/spec/Overview.html#structu

RE: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

[Israel Hilerio]

On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote:
> On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio 
> wrote:
> >> >> In addition, the index method in IDBObjectStore uses
> >> >> InvalidStateError to convey two different meanings: the object has
> >> >> been removed or deleted and the transaction being used finished.
> >> >> It seems that it would be better to separate these into:
> >> >> * InvalidStateError when the source object has been removed or
> deleted.
> >> >> * TransactionInactiveError when the transaction being used is inactive.
> >> >>
> >> >> What do you think?  I can open a bug if we agree this is the
> >> >> desired behavior.
> >> >
> >> >
> >> > Did this come out of the discussion here:
> >> >
> >> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.
> >> > htm
> >> > l
> >> >
> >> > If so, the rationale for which exception type to use is included,
> >> > although no-one on the thread was deeply averse to the alternative.
> >> > If it's a different issue can give a more specific example?
> >>
> >> Right. I think InvalidStateErr is better, for the reason detailed in
> >> the above referenced email.
> >>
> >> I agree we're using the same exception for two error conditions, but
> >> I'm not terribly worried that this will make debugging harder for authors.
> >>
> >> But I don't feel strongly so if there's a good reason I'm ok with
> >> changing things.
> >>
> >> / Jonas
> >>
> >
> > I agree that InvalidStateErr makes sense here.  The issue we're presenting 
> > is
> the use of one exception for two error conditions.
> > We just want to remove the ambiguity and cleanup of the language.  We
> have this issue in the IDBObjectStore.index and IDBTransaction.objectStore
> methods.
> >
> > One alternative could be to just leave "InvalidStateError" and remove the
> "or" clause from the description.
> > That would leave us with:
> >
> > 1. InvalidStateError - Occurs if a request is made on a source object that
> has been deleted or removed.
> >
> > Alternatively, we could add one more exception to capture the "or" clause:
> >
> > 2. TransactionInactiveError - Occurs if the transaction the object store
> belongs to has finished.
> >
> > I'm okay with only doing #1, if you all agree.  This simplifies things and
> captures the idea stated in the reference email.  Let me know what you think.
> 
> Hmm.. I think I'm not fully following you. Did you intend for #1 to change
> normative behavior, or to be an editorial clarification?
> 
> Simply removing the part after the "or" seems to result in a normative
> change since nowhere would we say that an exception should be thrown if
> index() is called after a transaction has finished. I.e. removing it would 
> mean
> that index() would have to return an IDBIndex instance even when called
> after the transaction has finished.
> 
> Maybe the solution is to change the text to something like: "Thrown if the
> function is called on a source object that has been deleted. Also thrown if 
> the
> transaction the object store belongs to has finished."
> 
> / Jonas

Sorry for the confusion.  My assumption for #1 was that it would be okay not to 
throw an exception 
if a developer were to make a call to IDBObjectStore.index and 
IDBTransaction.objectStore when
there is no transaction as long as any requests from those objects would throw 
TransactionInactiveError.
This would leave TransactionInactiveError to be thrown by methods that return 
IDBRequests only.

In Alternative #2, we were proposing to add TransactionInactiveError to the 
exception list to avoid the
exception overloading.  It just seems weird to overload InvalidStateError with 
multiple definitions.

Should we just do #2, then?

Israel

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 1:26 PM, Ian Hickson  wrote:

> On Tue, 24 Jan 2012, Glenn Adams wrote:
> >
> > Ian, I agree with the sentiment of your response ("take DOM4 right now
> and
> > publish it as a REC"). And, were it not for the W3C Process Document, we
> > might do just that. However, for the time being, we need to work within
> the
> > process document.
>
> Actually, no, we don't. We're sentient beings, our adherence to
> bureaucratic protocols is entirely voluntary.
>

Right. And last time I checked this is a W3C mailing list, a W3C group, and
W3C documents under discussion. So presumably we sentient beings have at
least implicitly signed up to the W3C Process (whether we agree with it or
not). Let's not continue to belabor this thread though since, as you say,
its beside the point. :)

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

DOM2 was not created for the purpose of reflecting the behavior in popular
implementations. So it would be misleading to use this rationale. I would
suggest the more neutral language I proposed above:

"Although DOM Level 2 continues to be subject to Errata
Management,
it is no longer being actively maintained. Content authors and implementers
are encouraged to consider the use of newer formulations of the Document
Object Model, including DOM4 , which is
currently in process for Advancing a Technical Report to
Recommendation
."

I believe this avoids any misreadings and has the intended effect of
warning authors/implementers about the status of DOM2 and its newer
formulation in progress.

On Tue, Jan 24, 2012 at 1:21 PM, Jonas Sicking  wrote:

> I think the point that is most important to me to capture is that DOM2
> no longer reflects the behavior in many browsers.
>
> So how about:
>
> DOM2 is no longer updated and doesn't in all cases reflect behavior in
> popular implementations. DOM4 is the latest actively maintained and
> updated version. 
>
> / Jonas
>
> 2012/1/24 Ojan Vafai :
> > Can we just compromise on the language here? I don't think we'll find
> > agreement on the proper way to do spec work.
> >
> > How about: "DOM2 is no longer updated. DOM4 is the latest actively
> > maintained version. "
> >
> >
> > On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams  wrote:
> >>
> >> I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same
> >> as saying DOM2 is a WIP. This is because the former can be read as
> saying
> >> that the normative content of DOM2 is now replaced with DOM4.
> >>
> >> I'm not sure what you mean by "[DOM2] is a work on which progress has
> >> stopped". DOM2 is a REC, and is only subject to errata [1] and
> rescinding
> >> [2].
> >>
> >> [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify
> >> [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind
> >>
> >> I'm not sure where the proposed obsolescence message falls in terms of
> [1]
> >> or [2]. Perhaps you could clarify, since presumably the process document
> >> will apply to any proposed change.
> >>
> >> On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger  wrote:
> >>>
> >>> On 01/24/2012 08:33 PM, Glenn Adams wrote:
> 
>  The problem is that the proposal (as I understand it) is to insert
>  something like:
> 
>  "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
> 
>  This addition is tantamount (by the reading of some) to demoting the
>  status
>  of DOM2 to "a work in progress".
> >>>
> >>>
> >>> Not at all; it's a work on which progress has stopped long ago.
> >>>
> >>
> >
>

Re: Obsolescence notices on old specifications, again

[Ian Hickson]

On Tue, 24 Jan 2012, Glenn Adams wrote:
>
> Ian, I agree with the sentiment of your response ("take DOM4 right now and
> publish it as a REC"). And, were it not for the W3C Process Document, we
> might do just that. However, for the time being, we need to work within the
> process document.

Actually, no, we don't. We're sentient beings, our adherence to 
bureaucratic protocols is entirely voluntary.

But that's besides the point, which was just that we should make it clear 
to readers of drafts that are out of date that those drafts are no longer 
the most useful documents available.

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

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

Ian, I agree with the sentiment of your response ("take DOM4 right now and
publish it as a REC"). And, were it not for the W3C Process Document, we
might do just that. However, for the time being, we need to work within the
process document. The best way to do that is attempt to (as rapidly as
possible) obtain consensus on publishing DOM4 as a LC then quickly progress
to CR. I personally (and the member I represent) will do whatever I (we)
can to assist in that process. And the same applies for the other WIP DOM
related specs.

On Tue, Jan 24, 2012 at 1:15 PM, Ian Hickson  wrote:

> On Tue, 24 Jan 2012, Glenn Adams wrote:
> > On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai  wrote:
> > >
> > > You keep saying this throughout this thread without pointing to
> > > specifics. It's impossible to argue with broad, sweeping
> > > generalizations like this. So far, you have yet to point to one
> > > concrete organization/statute that cares about REC status.
> >
> > Ojan, apparently you are not familiar with international or national
> > standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I
> > could give you a list of hundreds if you wish, all having encoded such
> > rules into their formal processes.
>
> I've no problem with providing stale snapshots for use by standards
> organisations and governments stuck with outdated models. That's fine.
> Nobody is saying that we should remove DOM2 altogether. Indeed, I've been
> arguing we should publish snapshots _more often_. I say we take DOM4 right
> now and publish it as a REC, and then do that every 6 months. That's the
> best way to serve organisations that need this artificial "stability".
>
> The point is to make sure that people reading the stale documents know
> that that is what they are doing. That's why the proposal is merely to
> have a warning on the stale documents, not remove them altogether.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: Obsolescence notices on old specifications, again

[Jonas Sicking]

I think the point that is most important to me to capture is that DOM2
no longer reflects the behavior in many browsers.

So how about:

DOM2 is no longer updated and doesn't in all cases reflect behavior in
popular implementations. DOM4 is the latest actively maintained and
updated version. 

/ Jonas

2012/1/24 Ojan Vafai :
> Can we just compromise on the language here? I don't think we'll find
> agreement on the proper way to do spec work.
>
> How about: "DOM2 is no longer updated. DOM4 is the latest actively
> maintained version. "
>
>
> On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams  wrote:
>>
>> I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same
>> as saying DOM2 is a WIP. This is because the former can be read as saying
>> that the normative content of DOM2 is now replaced with DOM4.
>>
>> I'm not sure what you mean by "[DOM2] is a work on which progress has
>> stopped". DOM2 is a REC, and is only subject to errata [1] and rescinding
>> [2].
>>
>> [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify
>> [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind
>>
>> I'm not sure where the proposed obsolescence message falls in terms of [1]
>> or [2]. Perhaps you could clarify, since presumably the process document
>> will apply to any proposed change.
>>
>> On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger  wrote:
>>>
>>> On 01/24/2012 08:33 PM, Glenn Adams wrote:

 The problem is that the proposal (as I understand it) is to insert
 something like:

 "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."

 This addition is tantamount (by the reading of some) to demoting the
 status
 of DOM2 to "a work in progress".
>>>
>>>
>>> Not at all; it's a work on which progress has stopped long ago.
>>>
>>
>

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 1:12 PM, Boris Zbarsky  wrote:

> On 1/24/12 8:58 PM, Glenn Adams wrote:
>
>>
>> 2012/1/24 Ojan Vafai mailto:o...@chromium.org>>
>>
>>
>>Can we just compromise on the language here? I don't think we'll
>>find agreement on the proper way to do spec work.
>>
>>How about: "DOM2 is no longer updated. DOM4 is the latest actively
>>maintained version. "
>>
>>
>> That doesn't really work for me. What would work for me is something like:
>>
>> "Although DOM Level 2 continues to be subject to Errata Management
>>
>
> Except it's not.  As far as I know, errata haven't been published for
> close to a decade now, and there are no plans to publish any.  This in
> spite of known things that need errata.
>

As long as the W3C Process Document [1] applies, DOM2 is "subject" to
Errata Management until such a time as it is formally Rescinded. It matters
not whether there are any plans to publish errata or not.

[1] http://www.w3.org/2005/10/Process-20051014/

Re: Obsolescence notices on old specifications, again

[Ian Hickson]

On Tue, 24 Jan 2012, Glenn Adams wrote:
> On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai  wrote:
> > 
> > You keep saying this throughout this thread without pointing to 
> > specifics. It's impossible to argue with broad, sweeping 
> > generalizations like this. So far, you have yet to point to one 
> > concrete organization/statute that cares about REC status.
> 
> Ojan, apparently you are not familiar with international or national 
> standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I 
> could give you a list of hundreds if you wish, all having encoded such 
> rules into their formal processes.

I've no problem with providing stale snapshots for use by standards 
organisations and governments stuck with outdated models. That's fine. 
Nobody is saying that we should remove DOM2 altogether. Indeed, I've been 
arguing we should publish snapshots _more often_. I say we take DOM4 right 
now and publish it as a REC, and then do that every 6 months. That's the 
best way to serve organisations that need this artificial "stability".

The point is to make sure that people reading the stale documents know 
that that is what they are doing. That's why the proposal is merely to 
have a warning on the stale documents, not remove them altogether.

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

Re: Obsolescence notices on old specifications, again

[Boris Zbarsky]

On 1/24/12 8:58 PM, Glenn Adams wrote:


2012/1/24 Ojan Vafai mailto:o...@chromium.org>>

Can we just compromise on the language here? I don't think we'll
find agreement on the proper way to do spec work.

How about: "DOM2 is no longer updated. DOM4 is the latest actively
maintained version. "


That doesn't really work for me. What would work for me is something like:

"Although DOM Level 2 continues to be subject to Errata Management


Except it's not.  As far as I know, errata haven't been published for 
close to a decade now, and there are no plans to publish any.  This in 
spite of known things that need errata.


Or in other words, DOM Level 2 contains text that is known to be "wrong" 
and there are no plans to fix that in DOM Level 2.  That's the problem 
people have with treating it as normative, sort of.


The rest of your proposed verbiage looks fine, but I guess I don't care 
that much about the verbiage here.


-Boris

Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

[Jonas Sicking]

On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio  wrote:
>> >> In addition, the index method in IDBObjectStore uses
>> >> InvalidStateError to convey two different meanings: the object has
>> >> been removed or deleted and the transaction being used finished.  It
>> >> seems that it would be better to separate these into:
>> >> * InvalidStateError when the source object has been removed or deleted.
>> >> * TransactionInactiveError when the transaction being used is inactive.
>> >>
>> >> What do you think?  I can open a bug if we agree this is the desired
>> >> behavior.
>> >
>> >
>> > Did this come out of the discussion here:
>> >
>> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.htm
>> > l
>> >
>> > If so, the rationale for which exception type to use is included,
>> > although no-one on the thread was deeply averse to the alternative. If
>> > it's a different issue can give a more specific example?
>>
>> Right. I think InvalidStateErr is better, for the reason detailed in the 
>> above
>> referenced email.
>>
>> I agree we're using the same exception for two error conditions, but I'm not
>> terribly worried that this will make debugging harder for authors.
>>
>> But I don't feel strongly so if there's a good reason I'm ok with changing
>> things.
>>
>> / Jonas
>>
>
> I agree that InvalidStateErr makes sense here.  The issue we're presenting is 
> the use of one exception for two error conditions.
> We just want to remove the ambiguity and cleanup of the language.  We have 
> this issue in the IDBObjectStore.index and IDBTransaction.objectStore methods.
>
> One alternative could be to just leave "InvalidStateError" and remove the 
> "or" clause from the description.
> That would leave us with:
>
> 1. InvalidStateError - Occurs if a request is made on a source object that 
> has been deleted or removed.
>
> Alternatively, we could add one more exception to capture the "or" clause:
>
> 2. TransactionInactiveError - Occurs if the transaction the object store 
> belongs to has finished.
>
> I'm okay with only doing #1, if you all agree.  This simplifies things and 
> captures the idea stated in the reference email.  Let me know what you think.

Hmm.. I think I'm not fully following you. Did you intend for #1 to
change normative behavior, or to be an editorial clarification?

Simply removing the part after the "or" seems to result in a normative
change since nowhere would we say that an exception should be thrown
if index() is called after a transaction has finished. I.e. removing
it would mean that index() would have to return an IDBIndex instance
even when called after the transaction has finished.

Maybe the solution is to change the text to something like: "Thrown if
the function is called on a source object that has been deleted. Also
thrown if the transaction the object store belongs to has finished."

/ Jonas

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

On Tuesday, January 24, 2012 2:46 AM Jonas Sicking wrote:
> On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio 
> wrote:
> > On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
> >> On Fri, Jan 20, 2012 at 12:23 PM, ben turner 
> wrote:
> >> > Mozilla is fine with removing the special |keyPath:""| behavior.
> >> > Please note that this will also mean that step 1 of the algorithm
> >> > here
> >> >
> >> >
> >> > http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-step
> >> > s-f or-extracting-a-key-from-a-value-using-a-key-path
> >> >
> >> > will need to change.
> >> >
> >> > We do want to continue to allow set behavior without specifying the
> >> > key twice, though, so we would propose adding an additional option
> >> > to createObjectStore to accomplish this:
> >> >
> >> >  // Old way:
> >> >  var set = db.createObjectStore("mySet", { keyPath:"" });
> >> >  set.put(keyValue);
> >> >
> >> >  // New way:
> >> >  var set = db.createObjectStore("mySet", { isSet: true });
> >> >  set.put(keyValue);
> >> >
> >> > (We are not in love with "isSet", better names are highly
> >> > encouraged!)
> >> >
> >> > What do you all think? This would allow us to continue to support
> >> > nice set behavior without making the empty string "magic".
> >>
> >> I actually think that the current behavior that we have is pretty
> >> consistent. Any time you give the keyPath property a string we create
> >> an objectStore with a keyPath. And any time you have an objectStore
> >> with a keyPath you are not allowed to pass an explicit key since the
> >> key is gotten from the keyPath. There's no special handling of empty
> strings happening.
> >>
> >> But I do agree that it can be somewhat confusing to tell
> >> ""/null/undefined apart since they are all falsy. In particular, an
> >> expression like
> >>
> >> if (myObjectStore.keyPath) {
> >>   ...
> >> }
> >>
> >> doesn't work to test if an objectStore has a keyPath or not. You
> >> instead need to check
> >>
> >> if (myObjectStore.keyPath != null) {
> >>   ...
> >> }
> >>
> >> or
> >>
> >> if (typeof myObjectStore.keyPath == "string") {
> >>   ...
> >> }
> >>
> >> Hence the "isSet" suggestion.
> >>
> >> Though I also realized after talking to Ben that empty keyPaths show
> >> up in indexes too. Consider creating a objectStore which maps peoples
> >> names to email addresses. Then you can create an index when does the
> >> opposite mapping, or which ensures that email addresses are unique:
> >>
> >> var store = db.createObjectStore("people"); var index =
> >> store.createIndex("reverse", "", { unique: true });
> >> store.add("john@email.com", "John Doe");
> >> store.add("m...@smith.org", "Mike Smith");
> >>
> >> store.get("John Doe").onsuccess = function(e) {
> >>   alert("John's email is " + e.target.result); }
> >>index.getKey("m...@smith.org").onsuccess = function(e) {
> >>   alert("m...@smith.org is owned by " + e.target.result); }
> >>
> >> Are people proposing we remove empty keyPaths here too?
> >>
> >> / Jonas
> >
> > Yes, I'm proposing removing empty string KeyPaths all together to avoid
> confusion.
> > I would like to know how often you expect developers to follow this
> > pattern instead of using objects.  Our believe is that objects will be
> > the main value stored in object stores instead of single values.
> >
> > Supporting keyPath with empty strings brings up all kinds of side effects.
> For example:
> >
> > var store = db.createObjectStore("people"); var index =
> > store.createIndex("reverse", "", { unique: true });
> > store.add({email: "john@email.com"}, "John Doe");
> > store.add({email: "m...@smith.org"},"Mike Smith");
> >
> > What should happen in this case, do we throw an exception?
> 
> This doesn't seem any different from
> 
> var store = db.createObjectStore("people"); var index =
> store.createIndex("reverse", "x", { unique: true }); store.add({ x: {email:
> "john@email.com"} }, "John Doe"); store.add({ x: {email:
> "m...@smith.org"} },"Mike Smith");
> 
> IIRC we decided a while ago that indexes do not add constraints. I.e.
> that if the keyPath for an index doesn't yield a valid key, then the index
> simply doesn't get an entry pointing to newly stored value.
> 
> So I don't really see that empty keyPaths bring up any special cases.
> The only special case we have in Firefox for empty keyPaths (apart from the
> keyPath evaluation code itself) is the code that throws an exception if you 
> try
> to create an objectStore with an empty keyPath and a key generator.
> 
> > Having some type of flag seems more promising for object stores.
> > However, we still need to figure out how to deal with Indexes on sets, do
> we pass another flag to support the indexes on sets?  If we do that, then
> what do we do with the keyPath parameter to an index.
> > It seems we're overloading the functionality of these methods to support
> different patterns.
> 
> Indeed, supporting the same use cases but using something other than
> empty key paths ge

Re: Obsolescence notices on old specifications, again

[Andres Riofrio]

I like Glenn's idea of being verbose to avoid ambiguity. It is a
spec---might as well spell out the consequences of the notice. :)

Andres Riofrio



2012/1/24 Glenn Adams 

>
> 2012/1/24 Ojan Vafai 
>
>> Can we just compromise on the language here? I don't think we'll find
>> agreement on the proper way to do spec work.
>>
>> How about: "DOM2 is no longer updated. DOM4 is the latest actively
>> maintained version. "
>>
>
> That doesn't really work for me. What would work for me is something like:
>
> "Although DOM Level 2 continues to be subject to Errata 
> Management,
> it is no longer being actively maintained. Content authors and implementers
> are encouraged to consider the use of newer formulations of the Document
> Object Model, including DOM4 , which is
> currently in process for Advancing a Technical Report to 
> Recommendation
> ."
>

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai  wrote:

> You keep saying this throughout this thread without pointing to specifics.
> It's impossible to argue with broad, sweeping generalizations like this. So
> far, you have yet to point to one concrete organization/statute that cares
> about REC status.
>

Ojan, apparently you are not familiar with international or national
standards bodies. To mention just a couple, ANSI, ISO, and ITU care. I
could give you a list of hundreds if you wish, all having encoded such
rules into their formal processes.

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

2012/1/24 Ojan Vafai 

> Can we just compromise on the language here? I don't think we'll find
> agreement on the proper way to do spec work.
>
> How about: "DOM2 is no longer updated. DOM4 is the latest actively
> maintained version. "
>

That doesn't really work for me. What would work for me is something like:

"Although DOM Level 2 continues to be subject to Errata
Management,
it is no longer being actively maintained. Content authors and implementers
are encouraged to consider the use of newer formulations of the Document
Object Model, including DOM4 , which is
currently in process for Advancing a Technical Report to
Recommendation
."

Re: Obsolescence notices on old specifications, again

[Ojan Vafai]

On Tue, Jan 24, 2012 at 11:50 AM, Glenn Adams  wrote:

>
> On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson  wrote:
>
>> On Tue, 24 Jan 2012, Glenn Adams wrote:
>> >
>> > The problem is that the proposal (as I understand it) is to insert
>> > something like:
>> >
>> > "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
>> >
>> > This addition is tantamount (by the reading of some) to demoting the
>> > status of DOM2 to "a work in progress".
>>
>> It should be:
>>
>> "DOM2 (a stale document) is obsolete. Use DOM4 (a work that is actively
>> maintained)."
>>
>
> It would be more accurate perhaps to say that DOM4 is "a work that is
> under active development". In the minds of most readers, "maintenance" is
> an errata process that follows completion (REC status).
>

I don't think the distinctions you are making here really matter. How
about: "DOM2 is no longer updated. DOM4 is under active development. ".

It doesn't "demote" DOM2 to "a work in progress", because "a work in
>> progress" is a step _up_ from where DOM2 is now.
>
>
> Many (most?) government, industry, and business activities that formally
> utilize W3C specifications would view a work in progress as less mature
> than a REC. That results in the form being assigned a lower value than the
> latter. So, yes, demote is the correct word.
>

You keep saying this throughout this thread without pointing to specifics.
It's impossible to argue with broad, sweeping generalizations like this. So
far, you have yet to point to one concrete organization/statute that cares
about REC status.

Re: Obsolescence notices on old specifications, again

[Jarred Nicholls]

2012/1/24 Glenn Adams 

> The problem is that the proposal (as I understand it) is to insert
> something like:
>
> "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
>
> This addition is tantamount (by the reading of some) to demoting the
> status of DOM2 to "a work in progress".
>

Clearly we need to be careful with our choice of words, though in this case
I wouldn't go as far as saying a stale document becomes a work in progress
when clearly the work in progress is a step forward and the state document
is the one no longer progressing.  But let's not perpetuate this
back-and-forth.  How about we get some proposed verbiage for individual
specs and discuss further at that point.  I think we all agree that a
notice in some form would be beneficial as long as its intent is clear.


>
>
> 2012/1/24 Bronislav Klučka 
>
>> Hello,
>> I do understand the objection, but how relevant should it be here? If
>> some regulation/law dictates that work must follow e.g. DOM 2, than it does
>> not matter that it's obsolete... The law takes precedence here regardless
>> of status of the document. Technically in such case one don't need to worry
>> himself about any progress or status of such document or specification.
>>
>>
>> On 23.1.2012 19:06, Glenn Adams wrote:
>>
>>> I object to adding such notice until all of the proposed replacement
>>> specs reach REC status.
>>>
>>> G.
>>>
>>>  Brona
>>
>>

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson  wrote:

> On Tue, 24 Jan 2012, Glenn Adams wrote:
> >
> > The problem is that the proposal (as I understand it) is to insert
> > something like:
> >
> > "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
> >
> > This addition is tantamount (by the reading of some) to demoting the
> > status of DOM2 to "a work in progress".
>
> It should be:
>
> "DOM2 (a stale document) is obsolete. Use DOM4 (a work that is actively
> maintained)."
>

It would be more accurate perhaps to say that DOM4 is "a work that is under
active development". In the minds of most readers, "maintenance" is an
errata process that follows completion (REC status).


>
> It doesn't "demote" DOM2 to "a work in progress", because "a work in
> progress" is a step _up_ from where DOM2 is now.


Many (most?) government, industry, and business activities that formally
utilize W3C specifications would view a work in progress as less mature
than a REC. That results in the form being assigned a lower value than the
latter. So, yes, demote is the correct word.

I understand your agenda is to reverse this way of thinking. I have no
objection to that agenda per se. But it is not an agenda shared by many
members of the W3C. If you think I'm wrong about this, then I'd like to see
a poll or ballot that quantifies the membership's perspective on this issue.

Re: Obsolescence notices on old specifications, again

[Ojan Vafai]

Can we just compromise on the language here? I don't think we'll find
agreement on the proper way to do spec work.

How about: "DOM2 is no longer updated. DOM4 is the latest actively
maintained version. "

On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams  wrote:

> I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same
> as saying DOM2 is a WIP. This is because the former can be read as saying
> that the normative content of DOM2 is now replaced with DOM4.
>
>  I'm not sure what you mean by "[DOM2] is a work on which progress has
> stopped". DOM2 is a REC, and is only subject to errata [1] and rescinding
> [2].
>
> [1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify
> [2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind
>
> I'm not sure where the proposed obsolescence message falls in terms of [1]
> or [2]. Perhaps you could clarify, since presumably the process document
> will apply to any proposed change.
>
> On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger  wrote:
>
>> On 01/24/2012 08:33 PM, Glenn Adams wrote:
>>
>>> The problem is that the proposal (as I understand it) is to insert
>>> something like:
>>>
>>> "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
>>>
>>> This addition is tantamount (by the reading of some) to demoting the
>>> status
>>> of DOM2 to "a work in progress".
>>>
>>
>> Not at all; it's a work on which progress has stopped long ago.
>>
>>
>

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

I'm sorry, but for some, saying DOM2 (a REC) = DOM4 (a WIP), is the same as
saying DOM2 is a WIP. This is because the former can be read as saying that
the normative content of DOM2 is now replaced with DOM4.

I'm not sure what you mean by "[DOM2] is a work on which progress has
stopped". DOM2 is a REC, and is only subject to errata [1] and rescinding
[2].

[1] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-modify
[2] http://www.w3.org/2005/10/Process-20051014/tr.html#rec-rescind

I'm not sure where the proposed obsolescence message falls in terms of [1]
or [2]. Perhaps you could clarify, since presumably the process document
will apply to any proposed change.

On Tue, Jan 24, 2012 at 12:36 PM, Ms2ger  wrote:

> On 01/24/2012 08:33 PM, Glenn Adams wrote:
>
>> The problem is that the proposal (as I understand it) is to insert
>> something like:
>>
>> "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
>>
>> This addition is tantamount (by the reading of some) to demoting the
>> status
>> of DOM2 to "a work in progress".
>>
>
> Not at all; it's a work on which progress has stopped long ago.
>
>

Re: Obsolescence notices on old specifications, again

[Ian Hickson]

On Tue, 24 Jan 2012, Glenn Adams wrote:
>
> The problem is that the proposal (as I understand it) is to insert 
> something like:
> 
> "DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."
> 
> This addition is tantamount (by the reading of some) to demoting the 
> status of DOM2 to "a work in progress".

It should be:

"DOM2 (a stale document) is obsolete. Use DOM4 (a work that is actively 
maintained)."

It doesn't "demote" DOM2 to "a work in progress", because "a work in 
progress" is a step _up_ from where DOM2 is now.

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

Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Jonas Sicking]

On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell  wrote:
> On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking  wrote:
>>
>> On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell  wrote:
>> > There's another edge case here - what happens on a put (etc) request to
>> > an
>> > object store with a key generator when the object store's key path does
>> > not
>> > yield a value, yet the algorithm below exits without changing the value.
>> >
>> > Sample:
>> >
>> > store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement:
>> > true});
>> > request = store.put("value");
>> >
>> > 3.2.5 for "put" has this error case "The object store uses in-line keys
>> > and
>> > the result of evaluating the object store's key path yields a value and
>> > that
>> > value is not a valid key." resulting in a DataError.
>>
>> The intent here was for something like:
>>
>> store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement:
>> true});
>> request = store.put({ a: { b: { hello: "world" } });
>>
>> In this case "4.7 Steps for extracting a key from a value using a key
>> path" will return the { hello: "world" } object which is not a valid
>> key and hence a DataError is thrown.
>>
>> > In this case, "4.7
>> > Steps for extracting a key from a value using a key path" says "no value
>> > is
>> > returned", so that error case doesn't apply.
>>
>> Yes, in your example that error is not applicable.
>>
>> > "5.1 Object Store Storage Operation" step 2 is: "If store uses a key
>> > generator and key is undefined, set key to the next generated key. If
>> > store
>> > also uses in-line keys, then set the property in value pointed to by
>> > store's
>> > key path to the new value for key."
>> >
>> > Per the algorithm below, the value would not change. (Another example
>> > would
>> > be a keyPath of "length" and putting [1,2,3])
>> >
>
>
> Although it's unimportant to the discussion below, I realized after the fact
> that my Array/length example was lousy since |length| is of course
> assignable.

Just to be perfectly clear and avoid any misunderstanding, the same
thing happens for non-assignable properties. For example:

store1 = db.createObjectStore("store1", { keyPath: "a.length",
autoIncrement: true});
store1.put({ a: "str" }); // stores an entry with key 3
store2 = db.createObjectStore("store2", { keyPath: "a.size",
autoIncrement: true});
store2.put({ a: my10KbBlob }); // stores an entry with key 10240

>> So, with that in mind we still need to figure out the various edge
>> cases and write a detailed set of steps for modifying a value using a
>> keyPath. In all these examples i'll assume that the key 1 is
>> generated. I've included the Firefox behavior in all cases, not
>> because I think it's obviously correct, but as a data point. I'm
>> curious to hear what you guys do too.
>>
>> What happens if a there are missing objects "higher up" in the keyPath:
>> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true
>> });
>> store.put({ x: "str" });
>> Here there is nowhere to directly store the new value since there is
>> no "a" property.
>> What we do in Firefox is to insert objects as needed. In this case
>> we'd modify the value such that we get the following:
>> { x: "str", a: { b: { c: 1 } } }
>> Same thing goes if part of the "object chain" is there:
>> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true
>> });
>> store.put({ x: "str", a: {} });
>> Here Firefox will again store { x: "str", a: { b: { c: 1 } } }
>>
>
> Per this thread/bug, I've landed a patch in Chromium to follow this
> behavior. Should be in Chrome Canary already and show up in 18.

Cool.

>> What happens if a value "higher up" in the keyPath is not an object:
>> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true
>> });
>> store.put({ a: "str" });
>> Here there not only is nowhere to directly store the new value. We
>> also can't simply insert the missing objects since we can't add a "b"
>> property to the value "str". Exact same scenario appears if you
>> replace "str" with a 1 or null.
>> What we do in Firefox is to throw a DataError exception.
>> Another example of this is simply
>> store = db.createObjectStore("os", { keyPath: "a", autoIncrement: true });
>> store.put("str");
>
> Chrome currently defers setting the new value until the transaction executes
> the asynchronous request, and thus doesn't raise an exception but fails the
> request. I agree that doing this at the time of the call makes more sense
> and is more consistent and predictable. If there's consensus here I'll file
> a bug against Chromium.

Awesome!

>> What happens if a value "higher up" in the keyPath is a host object:
>> store = db.createObjectStore("os", { keyPath: "a.b", autoIncrement: true
>> });
>> store.put({ a: myBlob });
>> While we can set a 'b' property on the blob, the structured clone
>> algorithm wouldn't copy this property and so it'd be pretty useless.
>> The exact same question applies if a is set t

Re: Obsolescence notices on old specifications, again

[Ms2ger]

On 01/24/2012 08:33 PM, Glenn Adams wrote:

The problem is that the proposal (as I understand it) is to insert
something like:

"DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."

This addition is tantamount (by the reading of some) to demoting the status
of DOM2 to "a work in progress".


Not at all; it's a work on which progress has stopped long ago.

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

The problem is that the proposal (as I understand it) is to insert
something like:

"DOM2 (a REC) is obsolete. Use DOM4 (a work in progress)."

This addition is tantamount (by the reading of some) to demoting the status
of DOM2 to "a work in progress".

2012/1/24 Bronislav Klučka 

> Hello,
> I do understand the objection, but how relevant should it be here? If some
> regulation/law dictates that work must follow e.g. DOM 2, than it does not
> matter that it's obsolete... The law takes precedence here regardless of
> status of the document. Technically in such case one don't need to worry
> himself about any progress or status of such document or specification.
>
>
> On 23.1.2012 19:06, Glenn Adams wrote:
>
>> I object to adding such notice until all of the proposed replacement
>> specs reach REC status.
>>
>> G.
>>
>>  Brona
>
>

RE: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods

[Israel Hilerio]

On Monday, January 23, 2012 8:22 PM, Jonas Sicking wrote:
> On Mon, Jan 23, 2012 at 5:17 PM, Joshua Bell  wrote:
> > On Mon, Jan 23, 2012 at 4:12 PM, Israel Hilerio
> > 
> > wrote:
> >>
> >> In looking at the count method in IDBObjectStore and IDBIndex we
> >> noticed that its signature doesn't throw a TransactionInactiveError
> >> when the transaction being used is inactive.  We would like to add this to
> the spec.
> >
> > Agreed. FWIW, this matches Chrome's behavior.
> 
> Same here.

Great!  I'll open a bug.

> 
> >> In addition, the index method in IDBObjectStore uses
> >> InvalidStateError to convey two different meanings: the object has
> >> been removed or deleted and the transaction being used finished.  It
> >> seems that it would be better to separate these into:
> >> * InvalidStateError when the source object has been removed or deleted.
> >> * TransactionInactiveError when the transaction being used is inactive.
> >>
> >> What do you think?  I can open a bug if we agree this is the desired
> >> behavior.
> >
> >
> > Did this come out of the discussion here:
> >
> > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.htm
> > l
> >
> > If so, the rationale for which exception type to use is included,
> > although no-one on the thread was deeply averse to the alternative. If
> > it's a different issue can give a more specific example?
> 
> Right. I think InvalidStateErr is better, for the reason detailed in the above
> referenced email.
> 
> I agree we're using the same exception for two error conditions, but I'm not
> terribly worried that this will make debugging harder for authors.
> 
> But I don't feel strongly so if there's a good reason I'm ok with changing
> things.
> 
> / Jonas
> 

I agree that InvalidStateErr makes sense here.  The issue we're presenting is 
the use of one exception for two error conditions.
We just want to remove the ambiguity and cleanup of the language.  We have this 
issue in the IDBObjectStore.index and IDBTransaction.objectStore methods.

One alternative could be to just leave "InvalidStateError" and remove the "or" 
clause from the description.
That would leave us with:

1. InvalidStateError - Occurs if a request is made on a source object that has 
been deleted or removed.

Alternatively, we could add one more exception to capture the "or" clause:

2. TransactionInactiveError - Occurs if the transaction the object store 
belongs to has finished.

I'm okay with only doing #1, if you all agree.  This simplifies things and 
captures the idea stated in the reference email.  Let me know what you think.

Israel

RE: CfC: to add Speech API to Charter; deadline January 24

[Adrian Bateman]

Microsoft is open to adding this to the WebApps charter.

We certainly want to see work on a speech API for user agents proceed at W3C. 
Our priorities for the API are 1) a procedural (JavaScript) API and 2) a 
declarative syntax for speech recognition and text-to-speech in HTML. We think 
WebApps would be a good venue to bring speech to the attention of members who 
wouldn't normally participate in this area. On the other hand we recognise that 
there may be some members who are interested in moving speech forward but who 
might not be willing to make IPR commitments for other specifications that 
WebApps works on. If that is the case then we'd rather have them involved in a 
separate working group than not benefit from their contributions.

Cheers,

Adrian.

On Friday, January 20, 2012 12:58 PM, Arthur Barstow wrote:
> The deadline for comments is extended to January *24*.
> 
> On 1/20/12 6:55 AM, ext Arthur Barstow wrote:
> > The deadline for comments is extended to January.
> >
> > Andrian, Maciej - I would appreciate it you would please provide some
> > feedback on this CfC.
> >
> > On 1/12/12 7:31 AM, ext Arthur Barstow wrote:
> >> Glen Shires and some others at Google proposed [1] that WebApps add
> >> Speech API to WebApps' charter and they put forward the Speech
> >> Javascript API Specification [2] as as a starting point. Members of
> >> Mozilla and Nuance have voiced various levels of support for this
> >> proposal. As such, this is a Call for Consensus to add Speech API to
> >> WebApps' charter.
> >>
> >> Positive response to this CfC is preferred and encouraged and silence
> >> will be considered as agreeing with the proposal. The deadline for
> >> comments is January 19 and all comments should be sent to
> >> public-webapps at w3.org.
> >>
> >> -AB
> >>
> >> [1]
> >> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.ht
> >> ml
> >> [2]
> >> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-169
> >> 6/speechapi.html
> >>
> >

Re: Obsolescence notices on old specifications, again

[Bronislav Klučka]

Hello,
I do understand the objection, but how relevant should it be here? If 
some regulation/law dictates that work must follow e.g. DOM 2, than it 
does not matter that it's obsolete... The law takes precedence here 
regardless of status of the document. Technically in such case one don't 
need to worry himself about any progress or status of such document or 
specification.


On 23.1.2012 19:06, Glenn Adams wrote:
I object to adding such notice until all of the proposed replacement 
specs reach REC status.


G.


Brona

Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Joshua Bell]

On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking  wrote:

> On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell  wrote:
> > There's another edge case here - what happens on a put (etc) request to
> an
> > object store with a key generator when the object store's key path does
> not
> > yield a value, yet the algorithm below exits without changing the value.
> >
> > Sample:
> >
> > store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement:
> > true});
> > request = store.put("value");
> >
> > 3.2.5 for "put" has this error case "The object store uses in-line keys
> and
> > the result of evaluating the object store's key path yields a value and
> that
> > value is not a valid key." resulting in a DataError.
>
> The intent here was for something like:
>
> store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement:
> true});
> request = store.put({ a: { b: { hello: "world" } });
>
> In this case "4.7 Steps for extracting a key from a value using a key
> path" will return the { hello: "world" } object which is not a valid
> key and hence a DataError is thrown.
>
> > In this case, "4.7
> > Steps for extracting a key from a value using a key path" says "no value
> is
> > returned", so that error case doesn't apply.
>
> Yes, in your example that error is not applicable.
>
> > "5.1 Object Store Storage Operation" step 2 is: "If store uses a key
> > generator and key is undefined, set key to the next generated key. If
> store
> > also uses in-line keys, then set the property in value pointed to by
> store's
> > key path to the new value for key."
> >
> > Per the algorithm below, the value would not change. (Another example
> would
> > be a keyPath of "length" and putting [1,2,3])
> >
>

Although it's unimportant to the discussion below, I realized after the
fact that my Array/length example was lousy since |length| is of course
assignable.


> > Chrome's current behavior in this case is that the put (etc) call returns
> > without raising an error, but an error event is raised against the
> request
> > indicating that the value could not be applied. This would imply having
> the
> > algorithm below return a success/failure indicator and having the steps
> in
> > 5.1 abort if the set fails.
> >
> > Thoughts?
>
> First off, I absolutely agree that we need to write an algorithm to
> exactly define how it works when a keyPath is used to modify a value.
> There are lots of edge cases here and it doesn't surprise me that the
> different implementations have ended up doing different things.
>
> But first, there seems to be at least two misconceptions in this thread.
>
> First off, modifying a value to insert a keyPath can never run into
> the situation when a value already exists. Consider the following:
>
> store1 = db.createObjectStore("mystore1", { keyPath: "a.b",
> autoIncrement: true });
> store1.put({ a: { b: 12 }});
> store2 = db.createObjectStore("mystore2", { keyPath: "length",
> autoIncrement: true });
> store2.put([1,2,3]);
>
> The first .put call will insert an entry with key 12 since the key
> already exists. So no modification will even be attempted, i.e. we'll
> never invoke the algorithm to modify a value using a keyPath. Same
> thing in the second .put call. Here a value already exists on the
> keyPath "length" and so an entry will be inserted with key 3. Again,
> we don't need to even invoke the steps for modifying a value using a
> keyPath.
>
> Please let me know if I'm missing something
>

Nope, totally clear.


> The second issue is how to modify a value if the keyPath used for
> modifying is the empty string. This situation can no longer occur
> since the change in bug 14985 [1]. Modifying values using keyPaths
> only happen when you use autoIncrement, and you can no longer use
> autoIncrement together with an empty-string keyPath since that is
> basically useless.
>

Also clear.

>
> So, with that in mind we still need to figure out the various edge
> cases and write a detailed set of steps for modifying a value using a
> keyPath. In all these examples i'll assume that the key 1 is
> generated. I've included the Firefox behavior in all cases, not
> because I think it's obviously correct, but as a data point. I'm
> curious to hear what you guys do too.
>
> What happens if a there are missing objects "higher up" in the keyPath:
> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true
> });
> store.put({ x: "str" });
> Here there is nowhere to directly store the new value since there is
> no "a" property.
> What we do in Firefox is to insert objects as needed. In this case
> we'd modify the value such that we get the following:
> { x: "str", a: { b: { c: 1 } } }
> Same thing goes if part of the "object chain" is there:
> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true
> });
> store.put({ x: "str", a: {} });
> Here Firefox will again store { x: "str", a: { b: { c: 1 } } }
>
>
Per this thread/bug, I've landed a patch in Chromium to follow thi

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 12:32 AM, Henri Sivonen  wrote:

> On Mon, Jan 23, 2012 at 10:38 PM, Glenn Adams  wrote:
> > I work in an industry where devices are certified against final
> > specifications, some of which are mandated by laws and regulations. The
> > current DOM-2 specs are still relevant with respect to these
> certification
> > processes and regulations.
>
> Which laws or regulations require compliance with some of the
> above-mentioned specs? Have bugs been filed on those laws and
> regulations?


I am referring to laws, regulations, and formal processes adopted by
various governments (e.g., U.S. and EU) and recognized international
standards organizations (e.g., ITU). One does not file bugs against laws
and regulations of this type. The industry I am referring to is television
broadcast, cable, satellite, and broadband services, much of which is
subject to national and international laws and regulations, some of which
refer (directly or indirectly) to W3C RECs, including the DOM RECs being
discussed here. With very few exceptions, the processes that govern these
laws and regulations require that any externally referenced document be
final, which, in the W3C process, means REC.

Re: Obsolescence notices on old specifications, again

[Glenn Adams]

On Tue, Jan 24, 2012 at 4:58 AM, Arthur Barstow wrote:

> Ms2ger,
>
> Last September, some obsolescence text was added to the DOM 2 Views REC:
>
> [[
> http://www.w3.org/TR/DOM-**Level-2-Views/#notice-20110922
> http://www.w3.org/TR/2000/REC-**DOM-Level-2-Views-20001113/
>
> *Document Status Update 2011-09-22*: This paragraph is informative. The
> concepts this document defines are obsolete. The 'document' and
> 'defaultView' attributes are defined in the HTML5 <
> http://www.w3.org/TR/html5/> specification with simplified semantics. The
> Web Applications Working Group 
> >
> encourages implementation of these concepts as defined by HTML5.
> ]]
>
> I think the proponents for adding obsolescence text to the other RECs
> should make a specific proposal for each REC.


I would support a notice akin to this, however, I am concerned about using
the term "obsolete" without having a normative substitute/replacement to
reference. I realize that the potential substitutes are not yet in REC
status, and will take some time to get there, and that it is possible to
add informative references to work in progress, but this doesn't quite
satisfy my notion of what obsolete means.

Re: CfC: to add Speech API to Charter; deadline January 24

[Dan Burnett]

On Jan 23, 2012, at 12:39 PM, Arthur Barstow wrote:

> On 1/23/12 12:17 PM, ext Charles McCathieNevile wrote:
>> On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires  wrote:
>> 
>>> 2. WebApps provides a balanced web-centric view for new JavaScript APIs.
>>> The XG group consisted of a large number of speech experts, but only a few 
>>> with broad web API expertise. We believe the formation of a new WG
>>> would have a similar imbalance,
>> 
>> I'm not sure this is necessarily the case, and the reverse possibility, that 
>> the Web Apps group would not have enough speech experts should also be 
>> considered a potential risk.
>> 
>>> whereas the WebApps WG can provide valuable, balanced guidance and
>>> feedback.
>> 
>> (FWIW I don't have a strong opinion on whether this is likely to be a real 
>> problem as opposed to a risk, and I think this conversation helps us work 
>> that out).
> 
> Another way to help us get the broadest set of stakeholders possible is for 
> the Speech work to be done in a new WG or an existing WG like with some 
> speech experts (Voice Browser WG or MMI WG?) and then to create some type of 
> joint task force with WebApps.
> 
> This would have the advantage that WebApps members would only have to make an 
> IP commitment for the specs created by the task force (and none of the other 
> WG's specs) and the other WG would not have to make an IP commitment for any 
> of WebApps' other specs. (Note we are already doing this for the Web Intents 
> spec and the Dev-API WG).
> 
> Is the VBWG or MMIWG interested in taking the lead on the speech spec?

We will discuss this in today's VBWG call.  As VBWG chair, I am a bit nervous 
about a joint deliverable.  They are extremely tricky to work out and have the 
disadvantage that a delay in either group delays overall progress.  However, 
dedicated workers can overcome most of these problems.
Personally, I agree with Debbie that a separate, dedicated Working Group has 
the double advantages of clear focus and easier IP commitments.

-- dan
(Speaking as both individual and VBWG chair in this email)
> 
> -AB
> 
> 
> 
> 
> 

Re: Obsolescence notices on old specifications, again

[Charles McCathieNevile]

On Tue, 24 Jan 2012 11:02:55 +0100, Ms2ger  wrote:


On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote:

* Ms2ger wrote:
The recent message to www-dom about DOM2HTML [1] made me realize that  
we still haven't added warnings to obsolete DOM specifications to  
hopefully avoid that people use them as a reference.


If you want to say more than that the specifications are no longer being
maintained and which newer specifications might contain more recent de-
finitions for the features covered you will have to create a process for
that first (it would require Advisory Committee review for instance, as
otherwise you are likely to create unnecessary drama).


I should have been clearer; this is indeed all I intend to say.


OK, this looks like the sort of message that Opera would support. As Art  
said, I think we need individual proposals per spec.


And I am not sure that rescinding specs we don't like much is necessarily  
a good idea.


cheers

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

Re: Obsolescence notices on old specifications, again

[Arthur Barstow]

Ms2ger,

Last September, some obsolescence text was added to the DOM 2 Views REC:

[[
http://www.w3.org/TR/DOM-Level-2-Views/#notice-20110922
http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/

*Document Status Update 2011-09-22*: This paragraph is informative. The 
concepts this document defines are obsolete. The 'document' and 
'defaultView' attributes are defined in the HTML5 
 specification with simplified semantics. 
The Web Applications Working Group  
encourages implementation of these concepts as defined by HTML5.

]]

I think the proponents for adding obsolescence text to the other RECs 
should make a specific proposal for each REC.


-AB

On 1/23/12 4:01 AM, ext Ms2ger wrote:

Hi all,

The recent message to www-dom about DOM2HTML [1] made me realize that 
we still haven't added warnings to obsolete DOM specifications to 
hopefully avoid that people use them as a reference.


I propose that we add a pointer to the contemporary specification to 
the following specifications:


* DOM 2 Core (DOM4)
* DOM 2 Views (HTML)
* DOM 2 Events (D3E)
* DOM 2 Style (CSSOM)
* DOM 2 Traversal and Range (DOM4)
* DOM 2 HTML (HTML)
* DOM 3 Core (DOM4)

and a recommendation against implementing the following specifications:

* DOM 3 Load and Save
* DOM 3 Validation

Hearing no objections, I'll try to move this forward.

Ms2ger

[1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[Jonas Sicking]

On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio  wrote:
> On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
>> On Fri, Jan 20, 2012 at 12:23 PM, ben turner  wrote:
>> > Mozilla is fine with removing the special |keyPath:""| behavior.
>> > Please note that this will also mean that step 1 of the algorithm here
>> >
>> >
>> > http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-f
>> > or-extracting-a-key-from-a-value-using-a-key-path
>> >
>> > will need to change.
>> >
>> > We do want to continue to allow set behavior without specifying the
>> > key twice, though, so we would propose adding an additional option to
>> > createObjectStore to accomplish this:
>> >
>> >  // Old way:
>> >  var set = db.createObjectStore("mySet", { keyPath:"" });
>> >  set.put(keyValue);
>> >
>> >  // New way:
>> >  var set = db.createObjectStore("mySet", { isSet: true });
>> >  set.put(keyValue);
>> >
>> > (We are not in love with "isSet", better names are highly encouraged!)
>> >
>> > What do you all think? This would allow us to continue to support nice
>> > set behavior without making the empty string "magic".
>>
>> I actually think that the current behavior that we have is pretty 
>> consistent. Any
>> time you give the keyPath property a string we create an objectStore with a
>> keyPath. And any time you have an objectStore with a keyPath you are not
>> allowed to pass an explicit key since the key is gotten from the keyPath. 
>> There's
>> no special handling of empty strings happening.
>>
>> But I do agree that it can be somewhat confusing to tell ""/null/undefined 
>> apart
>> since they are all falsy. In particular, an expression like
>>
>> if (myObjectStore.keyPath) {
>>   ...
>> }
>>
>> doesn't work to test if an objectStore has a keyPath or not. You instead 
>> need to
>> check
>>
>> if (myObjectStore.keyPath != null) {
>>   ...
>> }
>>
>> or
>>
>> if (typeof myObjectStore.keyPath == "string") {
>>   ...
>> }
>>
>> Hence the "isSet" suggestion.
>>
>> Though I also realized after talking to Ben that empty keyPaths show up in
>> indexes too. Consider creating a objectStore which maps peoples names to
>> email addresses. Then you can create an index when does the opposite
>> mapping, or which ensures that email addresses are unique:
>>
>> var store = db.createObjectStore("people"); var index =
>> store.createIndex("reverse", "", { unique: true });
>> store.add("john@email.com", "John Doe"); store.add("m...@smith.org",
>> "Mike Smith");
>>
>> store.get("John Doe").onsuccess = function(e) {
>>   alert("John's email is " + e.target.result); }
>> index.getKey("m...@smith.org").onsuccess = function(e) {
>>   alert("m...@smith.org is owned by " + e.target.result); }
>>
>> Are people proposing we remove empty keyPaths here too?
>>
>> / Jonas
>
> Yes, I'm proposing removing empty string KeyPaths all together to avoid 
> confusion.
> I would like to know how often you expect developers to follow this pattern
> instead of using objects.  Our believe is that objects will be the main value 
> stored in object stores
> instead of single values.
>
> Supporting keyPath with empty strings brings up all kinds of side effects. 
> For example:
>
> var store = db.createObjectStore("people");
> var index = store.createIndex("reverse", "", { unique: true });
> store.add({email: "john@email.com"}, "John Doe");
> store.add({email: "m...@smith.org"},"Mike Smith");
>
> What should happen in this case, do we throw an exception?

This doesn't seem any different from

var store = db.createObjectStore("people");
var index = store.createIndex("reverse", "x", { unique: true });
store.add({ x: {email: "john@email.com"} }, "John Doe");
store.add({ x: {email: "m...@smith.org"} },"Mike Smith");

IIRC we decided a while ago that indexes do not add constraints. I.e.
that if the keyPath for an index doesn't yield a valid key, then the
index simply doesn't get an entry pointing to newly stored value.

So I don't really see that empty keyPaths bring up any special cases.
The only special case we have in Firefox for empty keyPaths (apart
from the keyPath evaluation code itself) is the code that throws an
exception if you try to create an objectStore with an empty keyPath
and a key generator.

> Having some type of flag seems more promising for object stores.  However, we 
> still need to figure out how to deal with
> Indexes on sets, do we pass another flag to support the indexes on sets?  If 
> we do that, then what do we do with the keyPath parameter to an index.
> It seems we're overloading the functionality of these methods to support 
> different patterns.

Indeed, supporting the same use cases but using something other than
empty key paths gets pretty messy for indexes. If we want to keep
supporting these use cases (which I personally do), then I think using
empty key paths is the cleanest solution.

Really the only downside that I see is the somewhat non-intuitive
"objectStore.keyPath != null" check. But I'm not convince

Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

[Jonas Sicking]

On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell  wrote:
> There's another edge case here - what happens on a put (etc) request to an
> object store with a key generator when the object store's key path does not
> yield a value, yet the algorithm below exits without changing the value.
>
> Sample:
>
> store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement:
> true});
> request = store.put("value");
>
> 3.2.5 for "put" has this error case "The object store uses in-line keys and
> the result of evaluating the object store's key path yields a value and that
> value is not a valid key." resulting in a DataError.

The intent here was for something like:

store = db.createObjectStore("my-store", {keyPath: "a.b", autoIncrement: true});
request = store.put({ a: { b: { hello: "world" } });

In this case "4.7 Steps for extracting a key from a value using a key
path" will return the { hello: "world" } object which is not a valid
key and hence a DataError is thrown.

> In this case, "4.7
> Steps for extracting a key from a value using a key path" says "no value is
> returned", so that error case doesn't apply.

Yes, in your example that error is not applicable.

> "5.1 Object Store Storage Operation" step 2 is: "If store uses a key
> generator and key is undefined, set key to the next generated key. If store
> also uses in-line keys, then set the property in value pointed to by store's
> key path to the new value for key."
>
> Per the algorithm below, the value would not change. (Another example would
> be a keyPath of "length" and putting [1,2,3])
>
> Chrome's current behavior in this case is that the put (etc) call returns
> without raising an error, but an error event is raised against the request
> indicating that the value could not be applied. This would imply having the
> algorithm below return a success/failure indicator and having the steps in
> 5.1 abort if the set fails.
>
> Thoughts?

First off, I absolutely agree that we need to write an algorithm to
exactly define how it works when a keyPath is used to modify a value.
There are lots of edge cases here and it doesn't surprise me that the
different implementations have ended up doing different things.

But first, there seems to be at least two misconceptions in this thread.

First off, modifying a value to insert a keyPath can never run into
the situation when a value already exists. Consider the following:

store1 = db.createObjectStore("mystore1", { keyPath: "a.b",
autoIncrement: true });
store1.put({ a: { b: 12 }});
store2 = db.createObjectStore("mystore2", { keyPath: "length",
autoIncrement: true });
store2.put([1,2,3]);

The first .put call will insert an entry with key 12 since the key
already exists. So no modification will even be attempted, i.e. we'll
never invoke the algorithm to modify a value using a keyPath. Same
thing in the second .put call. Here a value already exists on the
keyPath "length" and so an entry will be inserted with key 3. Again,
we don't need to even invoke the steps for modifying a value using a
keyPath.

Please let me know if I'm missing something.

The second issue is how to modify a value if the keyPath used for
modifying is the empty string. This situation can no longer occur
since the change in bug 14985 [1]. Modifying values using keyPaths
only happen when you use autoIncrement, and you can no longer use
autoIncrement together with an empty-string keyPath since that is
basically useless.


So, with that in mind we still need to figure out the various edge
cases and write a detailed set of steps for modifying a value using a
keyPath. In all these examples i'll assume that the key 1 is
generated. I've included the Firefox behavior in all cases, not
because I think it's obviously correct, but as a data point. I'm
curious to hear what you guys do too.

What happens if a there are missing objects "higher up" in the keyPath:
store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true });
store.put({ x: "str" });
Here there is nowhere to directly store the new value since there is
no "a" property.
What we do in Firefox is to insert objects as needed. In this case
we'd modify the value such that we get the following:
{ x: "str", a: { b: { c: 1 } } }
Same thing goes if part of the "object chain" is there:
store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true });
store.put({ x: "str", a: {} });
Here Firefox will again store { x: "str", a: { b: { c: 1 } } }


What happens if a value "higher up" in the keyPath is not an object:
store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement: true });
store.put({ a: "str" });
Here there not only is nowhere to directly store the new value. We
also can't simply insert the missing objects since we can't add a "b"
property to the value "str". Exact same scenario appears if you
replace "str" with a 1 or null.
What we do in Firefox is to throw a DataError exception.
Another example of this is simply
store = db.createObjectStore("os", { 

Re: Obsolescence notices on old specifications, again

[Ms2ger]

On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote:

* Ms2ger wrote:

The recent message to www-dom about DOM2HTML [1] made me realize that we
still haven't added warnings to obsolete DOM specifications to hopefully
avoid that people use them as a reference.


If you want to say more than that the specifications are no longer being
maintained and which newer specifications might contain more recent de-
finitions for the features covered you will have to create a process for
that first (it would require Advisory Committee review for instance, as
otherwise you are likely to create unnecessary drama).


I should have been clearer; this is indeed all I intend to say.

HTH
Ms2ger

[Bug 14985] Specify how autoincrement + empty keypath works

[bugzilla]

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

Jonas Sicking  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jonas Sicking  2012-01-24 08:58:20 UTC ---
Empty string is still a valid keyPath, at least for now. You just can't use an
empty-string keyPath at the same time as you use a key generator since that is
basically useless (see examples in comment 0).

The intent of this bug was just to cover the interaction between empty keypaths
and autoincrement.

If we do end up killing empty keypaths that seems like a separate bug, so
closing this for now. If we end up killing empty keypaths i'll open a new bug.

Feel free to reopen if you don't agree or if I'm misunderstanding something.

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