Re: [Bug 11269] New: Evaluating keyPaths needs to be better specified

On Tue, Nov 9, 2010 at 3:38 AM, <bugzilla@jessica.w3.org> wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11269
>
>           Summary: Evaluating keyPaths needs to be better specified
>           Product: WebAppsWG
>           Version: unspecified
>          Platform: PC
>        OS/Version: All
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: Indexed Database API
>        AssignedTo: dave.null@w3.org
>        ReportedBy: jonas@sicking.cc
>         QAContact: member-webapi-cvs@w3.org
>                CC: mike@w3.org, public-webapps@w3.org
>
>
> This bug is very similar to bug 9832, however since that bug is discussing
> a
> lot of related issues, I wanted to file a separate one to make sure this
> isn't
> forgotten.
>
> Currently the syntax for parsing a keyPath isn't explicitly defined. It is
> clear that for keypath/object
>
> "foo.bar.baz"
> { foo: { bar: { baz: 4 } } }
>
> the result is 4. However does keypath/object
>
> "foo[1].bar"
> { foo: [ false, { bar: 4 }, true ] }
>
> evaluate to 4? What about
>

Chromium supports all of the examples you've listed so far.  Making it more
restrictive could be a good idea though.  Does anyone have specific
thoughts?



> "foo[x].bar"
> { foo: [ { bar: 4 } ], x: 0 }
>
> or
>
> ""
> 4
>
> Do either of those evaluate to 4? The last example could be useful when
> out-of-line keys are used, but still wanting to be able to search on the
> stored
> value.
>

This seems like a bit of a stretch for v1.

J