- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Wed, 27 Aug 2008 14:44:08 -0700
- To: "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: "Web Applications Working Group WG" <public-webapps@w3.org>
On Wed, Aug 27, 2008 at 2:39 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Garrett Smith wrote: >> >> Given that, I suggest moving forward: >> Test, then document those methods as having special behavior. Do >> this not by a null->value mapping, but by documenting the method's >> algorithm in simple terms. e.g. "if X is not a string, throw an error" > > But giving a (per-method) mapping means that the algorithm can then be > machine-generated from the IDL, which is an interoperability win: less > chance of a mistake being made. > > So why are you opposed to having such per-method mappings, as needed? > I can appreciate the desire to make the task of implementing the spec in an automated fashion. That is a desire, however, not a need. What I opposed is calling null a string. Null is not a string by the definition in the DOM 3 spec[1]. A String variable, in Java, can have the value null, but this can be determined: if(s == null). However, WebIDL does lump null into domstring. What WebIDL does creates compatibility issues in an attempt to standardize bugs. Moving forward, if null is allowed, it should not be called a string. However, if only a DOMString is allowed, and null is passed, it should not require a one-off mapping. Garrett [1] DOM3 domstring http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-C74D1578 [2] WebIDL domstring http://dev.w3.org/2006/webapi/WebIDL/#idl-DOMString > -Boris >
Received on Wednesday, 27 August 2008 21:44:46 UTC