[Bug 14985] Specify how autoincrement + empty keypath works
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985 Jonas Sicking jo...@sicking.cc changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #3 from Jonas Sicking jo...@sicking.cc 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.
Re: Obsolescence notices on old specifications, again
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
Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell jsb...@chromium.org 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, { keyPath: a, autoIncrement: true });
store.put(str);
What happens if a value higher up
Re: [indexeddb] Do we need to support keyPaths with an empty string?
On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio isra...@microsoft.com wrote:
On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com 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 convinced that this
is something that people will run in to a lot given that the main
use-case that I can think of is generic code which visualize a
indexedDB database for developers.
/ Jonas
Re: Obsolescence notices on old specifications, again
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 http://www.w3.org/2008/webapps/ 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: Obsolescence notices on old specifications, again
On Tue, 24 Jan 2012 11:02:55 +0100, Ms2ger ms2...@gmail.com 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: CfC: to add Speech API to Charter; deadline January 24
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 gshi...@google.com 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
On Tue, Jan 24, 2012 at 4:58 AM, Arthur Barstow art.bars...@nokia.comwrote: Ms2ger, Last September, some obsolescence text was added to the DOM 2 Views REC: [[ http://www.w3.org/TR/DOM-**Level-2-Views/#notice-20110922http://www.w3.org/TR/DOM-Level-2-Views/#notice-20110922 http://www.w3.org/TR/2000/REC-**DOM-Level-2-Views-20001113/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 http://www.w3.org/2008/**webapps/http://www.w3.org/2008/webapps/ 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: Obsolescence notices on old specifications, again
On Tue, Jan 24, 2012 at 12:32 AM, Henri Sivonen hsivo...@iki.fi wrote: On Mon, Jan 23, 2012 at 10:38 PM, Glenn Adams gl...@skynav.com 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: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell jsb...@chromium.org 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 this
behavior. Should be in Chrome Canary already and show up in 18.
What happens if a value higher up in the keyPath is not an object:
store = db.createObjectStore(os, {
Re: Obsolescence notices on old specifications, again
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: CfC: to add Speech API to Charter; deadline January 24
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] Missing TransactionInactiveError Exception type for count and index methods
On Monday, January 23, 2012 8:22 PM, Jonas Sicking wrote: On Mon, Jan 23, 2012 at 5:17 PM, Joshua Bell jsb...@chromium.org wrote: On Mon, Jan 23, 2012 at 4:12 PM, Israel Hilerio isra...@microsoft.com 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: Obsolescence notices on old specifications, again
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: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell jsb...@chromium.org 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 to a Date or a RegExp too.
In Firefox I actually think that we set a useless 'b' property on the
blob which I would say is a bug.
I believe Chrome does the same as Firefox here - assign a property which
will then fail to be serialized.
Whatever we
Re: Obsolescence notices on old specifications, again
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: Obsolescence notices on old specifications, again
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 ms2...@gmail.com 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
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. link to DOM4 On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com 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 ms2...@gmail.com 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
On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson i...@hixie.ch 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
2012/1/24 Glenn Adams gl...@skynav.com 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 bronislav.klu...@bauglir.com 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
On Tue, Jan 24, 2012 at 11:50 AM, Glenn Adams gl...@skynav.com wrote: On Tue, Jan 24, 2012 at 12:39 PM, Ian Hickson i...@hixie.ch 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. link to DOM4. 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
On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org 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
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 riofr...@gmail.com 2012/1/24 Glenn Adams gl...@skynav.com 2012/1/24 Ojan Vafai 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. link to DOM4 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 Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, 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 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance .
Re: Obsolescence notices on old specifications, again
On 1/24/12 8:58 PM, Glenn Adams wrote: 2012/1/24 Ojan Vafai o...@chromium.org 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. link to DOM4 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
On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio isra...@microsoft.com 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: Obsolescence notices on old specifications, again
On Tue, 24 Jan 2012, Glenn Adams wrote: On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org 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
On Tue, Jan 24, 2012 at 1:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/24/12 8:58 PM, Glenn Adams wrote: 2012/1/24 Ojan Vafai o...@chromium.org 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. link to DOM4 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, 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 i...@hixie.ch wrote: On Tue, 24 Jan 2012, Glenn Adams wrote: On Tue, Jan 24, 2012 at 12:58 PM, Ojan Vafai o...@chromium.org 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
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. link to DOM4 / Jonas 2012/1/24 Ojan Vafai 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. link to DOM4 On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com 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 ms2...@gmail.com 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
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
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 Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, 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 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance . 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 jo...@sicking.cc 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. link to DOM4 / Jonas 2012/1/24 Ojan Vafai 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. link to DOM4 On Tue, Jan 24, 2012 at 11:43 AM, Glenn Adams gl...@skynav.com 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 ms2...@gmail.com 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
On Tue, Jan 24, 2012 at 1:26 PM, Ian Hickson i...@hixie.ch 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: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods
On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote: On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio isra...@microsoft.com 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: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods
On Tue, Jan 24, 2012 at 12:33 PM, Israel Hilerio isra...@microsoft.com wrote: On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote: On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio isra...@microsoft.com 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#structured-clone / Jonas
Re: CfC: to add Speech API to Charter; deadline January 24
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 gshi...@google.com 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)
[Bug 15699] New: My phone does nt save when i download
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.
[Bug 15699] My phone does nt save when i download
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15699 Tab Atkins Jr. jackalm...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jackalm...@gmail.com Resolution||INVALID --- Comment #1 from Tab Atkins Jr. jackalm...@gmail.com 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.
Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods
On Tue, Jan 24, 2012 at 12:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jan 24, 2012 at 12:33 PM, Israel Hilerio isra...@microsoft.com wrote: On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote: On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio isra...@microsoft.com 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#structured-clone A few other examples of functions which throw the same exception for multiple types of errors: EventTarget.dispatchEvent [5]
IndexedDB: Extra properties in optionalParameters objects
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: Extra properties in optionalParameters objects
On Tue, Jan 24, 2012 at 2:36 PM, Joshua Bell jsb...@chromium.org 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: Extra properties in optionalParameters objects
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: CfC: to add Speech API to Charter; deadline January 24
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 adria...@microsoft.comwrote: 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: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
On Tuesday, January 24, 2012 11:38 AM, Jonas Sicking wrote:
On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell jsb...@chromium.org
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 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 to a Date or a RegExp too.
Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
On Tue, Jan 24, 2012 at 4:23 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Jan 24, 2012 at 4:16 PM, Israel Hilerio isra...@microsoft.com 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: Obsolescence notices on old specifications, again
* 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 Managementhttp://www.w3.org/2005/10/Process-20051014/tr.html#errata, 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 http://www.w3.org/TR/dom/, which is currently in process for Advancing a Technical Report to Recommendationhttp://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance . 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/
