IndexedDB: use of TypeError

So I didn't start working on/implementing indexedDB until after this
message went out:

http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0958.html

So I haven't had to face the full implications of using TypeError until
this week.

I'd like to (hopefully not too late) voice my opposition to TypeError for
the following scenarios:

   - invalid value for the 'direction' parameter to open*Cursor (must be
   'next', 'prev', 'nextunique', or 'prevunique')
   - advance(count) where count < 1
   - open(version) where version < 1

The problem here is that these are not easily enforceable by the WebIDL
spec, which means implementations have an extra burden of customizing their
WebIDL implementation to custom-annotate the IDL extend things like
[EnforceRange=Positive] or introducing JS semantics into their otherwise
JS-free code.

Now this certainly could just be an implementors complaint, but I feel like
I can retroactively justify it:

The rationale behind the current spec is that these are very similar to a
"range error" where the API has a very narrow range of values, that precede
any higher level semantic parameter constraints. But the problem is that
they still have some semantic value within IndexedDB - i.e. even though '0'
is a valid numeric value to JavaScript, it is invalid because of specific
consistencies within the IndexedDB spec. Even though "foo" is a valid
string to JavaScript, strings like "next" and "prev" are the only valid
strings because they have specific meaning in the context of IndexedDB.

So I'd argue that these errors should be indexeddb-specific errors, and/or
reused DOMExceptions. What I miss is the NotAllowedError that I believe in
an earlier version of the spec, but I could also believe that
DOMException's InvalidAccessError could also be used ("The object does not
support the operation or argument")

Alec