This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 5.1 "Object Store Storage Operation", step 2: when a key generator is used with store with in line keys, the spec says: "set the property in value pointed to by store's key path to the new value for key" The "steps for extracting a key from a value using a key path" are called out explicitly under Algorithms in 4.7. Should the steps for assigning a key to a value using a key path be similarly documented? Cribbing from the spec, this could read as: 4.X Steps for assigning a key to a value using a key path When taking the steps for assigning a key to a value using a key path, the implementation must run the following algorithm. The algorithm takes a key path named /keyPath/, a key named /key/, and a value named /value/ which may be modified by the steps of the algorithm. 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 /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 7. 4. If /object/ does not have an attribute named /attribute/, then skip the rest of these steps and /value/ is not modified. 5. Assign /object/ to be the /value/ of the attribute named /attribute/ on /object/. 6. Go to step 3. 7. NOTE: The steps leading here ensure that /remainingKeyPath/ is a single attribute name (i.e. string without periods) by this step. 8. Let /attribute/ be /remainingKeyPath/ 9. If /object/ has an attribute named /attribute/ which is not modifiable, then skip the remaining steps and /value/ is not modified. 10. Set an attribute named /attribute/ on /object/ with the value /key/. Notes: The above talks in terms of a mutable value. It could be amended to have an initial step which produces a clone of the value, which is later returned, but given how this algorithm is used the difference is not observable, since the value stored should already be a clone that doesn't have any other references. Step 9 is present in case the key path refers to a "special" property, e.g. a String/Array length, Blob/File properties, etc.
This is the set of steps people seemed to agree on after the thread in the mailing list: 1. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/. 2. if /object/ is not an Object object or an Array object (see structured clone algorithm), then throw a DOMException of type DataError. 3. 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 7. 4. If /object/ does not have an attribute named /attribute/, then create the attribute and assign it an empty object. 5. Assign /object/ to be the value of the attribute named /attribute/ on /object/. 6. Go to step 2. 7. 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. 8. Let /attribute/ be /remainingKeyPath/ 9. 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. every time before we run these steps we evaluate the keyPath against /value/ and only if that does not yield a value (where 'undefined' does count as a value) do we generate a key and use the above steps to modify /value/ to contain the generated key. Because of this we know that at step 10 the object does not have an attribute with name /attribute/.
Changes live in the Editor's draft of 29 February.