Bug 20394 - [IndexedDB] Spec should use WebIDL concepts such as sequence<T> rather than Array
[IndexedDB] Spec should use WebIDL concepts such as sequence<T> rather than A...
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API
unspecified
All All
: P2 normal
: ---
Assigned To: Joshua Bell
public-webapps-bugzilla
:
Depends on: 20582
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-14 18:59 UTC by Joshua Bell
Modified: 2013-04-15 20:43 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Bell 2012-12-14 18:59:51 UTC
In various places in the spec such as the interpretation of key path values, the spec explicitly defines special input for ECMAScript Arrays. Most of the rest of the platform defines this via WebIDL's ECMAScript binding which is closer to "duck typing" rather than "is-a". For example, an operation that accepts sequence<DOMString> would be satisfied by this input:

{ 'length': 2, '0': 'first', '1': 'second' }

... even though it is not an ECMAScript array.

This applies most easily to Key Paths, which are defined to be DOMStrings or Arrays of DOMStrings.

...

Both Chrome and Firefox do "is-a" checks here, but changing this wouldn't break anything. I don't think we need to do this for the v1 edition of the spec, but adhering more closely to WebIDL for v2 would be nice.
Comment 1 Boris Zbarsky 2012-12-14 19:04:27 UTC
For what it's worht, the current key setup just makes no sense at all in WebIDL terms.  When I looked into implementing it in a WebIDL binding for Firefox I had to just give up because it's completely nonsense.  See http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0087.html (which was met with deafening silence).

I think you do need to fix this for v1.  Certainly I would be objecting to the spec going to REC in its current state...
Comment 2 Joshua Bell 2012-12-14 19:10:22 UTC
(In reply to comment #1)
> For what it's worht, the current key setup just makes no sense at all in
> WebIDL terms.  When I looked into implementing it in a WebIDL binding for
> Firefox I had to just give up because it's completely nonsense.  See
> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0087.html
> (which was met with deafening silence).

I must have missed that, but +1. To maintain the intent behind IDB (and compatibility with shipping implementations) it probably turns into a bunch of additions to WebIDL. Not a bad thing, but will require spec coordination.
Comment 3 Boris Zbarsky 2012-12-14 19:13:40 UTC
It's not clear to me what parts of this really need to stay compatible with the mess implementations ship (nor how compatible they are with each other), for what it's worth.  But yes, we may end up needing WebIDL changes, depending. Please coordinate with Cameron ASAP, because WebIDL is in CR, so if you actually want substantive changes to it they need to happen _soon_.
Comment 4 Joshua Bell 2013-01-09 17:42:16 UTC
See 20582 for discussion around keys specifically, where we should probably take the spec in the other direction - less WebIDL, more ECMA-262.
Comment 5 Joshua Bell 2013-03-01 19:17:11 UTC
The bulk of the WebIDL fragments have been updated to use sequence<T> and T[] and unions as appropriate.

Bug 20582 cleans up the definition of keys to define them in terms of ECMAScript objects rather than a hybrid of ES and WebIDL.

What's left is a smattering of uses of <code>Array</code> throughout the spec far away from the method input definitions. Most of those are around keys (which should now be correct) but some are around key paths; those should more abstractly refer to a sequences, lists, or sets, not the input type.
Comment 6 Boris Zbarsky 2013-04-02 18:08:15 UTC
There are still issues here for keyPath.  I filed bug 21555 on those.
Comment 7 Joshua Bell 2013-04-15 20:43:13 UTC
(In reply to comment #5)
> What's left is a smattering of uses of <code>Array</code> throughout the
> spec far away from the method input definitions. Most of those are around
> keys (which should now be correct) but some are around key paths; those
> should more abstractly refer to a sequences, lists, or sets, not the input
> type.

(In reply to comment #6)
> There are still issues here for keyPath.  I filed bug 21555 on those.

Apart from the issues in 21555, I've updated the places that describe array-type key paths to use sequence<DOMString> consistently in https://dvcs.w3.org/hg/IndexedDB/rev/5d920000beba

The pedantic part of me would like to take this further and refer to them even more abstractly as "sequences of strings" but this is probably sufficient.