W3C home > Mailing lists > Public > public-webapi@w3.org > June 2007

Re: Bindings spec ready for FPWD?

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 28 Jun 2007 13:57:09 +1000
To: public-webapi@w3.org
Message-ID: <20070628035709.GE6116@arc.mcc.id.au>

Ian Hickson:
> Wow, that's awesome. Ship it!

Thanks.

> Some comments:
> 
> In 2.8.2 you have IndexPutter and NamePutter which i presume should be 
> Setters rather than Putters.

Fixed.

> Regarding the 3.2.2 ed note, I vote for giving a mandated way; otherwise 
> when people rely on a particular chain, it'll break in another browser and 
> eventually all the browsers will have to do whatever IE picked (when they 
> implement this).

The problem with mandating it is that no browser currently implements it
exactly as I’ve done in the example, AFAIK.  Given that you can’t
normally navigate the prototype chain from script anyway (well, Mozilla
seems to have .__proto__ properties to access [[Prototype]]), it’d be
sufficient to specify it with some lower level of detail, as Boris
suggested in the last para of
http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0022.html .
I haven’t really captured that yet with the single paragraph above the
example, but expanding it out a bit with some specific conditions that
have to hold about calling [[Get]]/[[Put]] on host objects and interface
prototype objects might be enough.

> It would be nice if the spec could suggest some boilerplate text for other 
> specs to include, in the way that RFC2119 does. For example:
> 
>    IDL sections in this specification must be interpreted and implemented 
>    as required by the "Language Bindings for DOM Specifications" 
>    specification. [DOMBIND]

Good idea.  I’ll put something like that in the conformance section when
I get to it.

> Is there anything else that a spec would have to do other than say 
> something like the above and then use the various features you define? 
> e.g. is there ever a case where prose is necessary to fully define 
> something?

There are some cases that aren’t covered by the spec currently, like the
Image/Option/etc. constructor functions from HTML 5.  I haven’t gone
through HTML 5 in detail yet to check if I’ve missed anything else.

But you could imagine a spec requiring a [[Get]] method that does
something in particular, which wouldn’t really be worth putting in the
Bindings spec because it’s too specific.

> Is it necessary to explicitly list the exceptions that a method, getter, 
> or setter can raise?

Good question.  OMG IDL says:

  The absence of a raises expression on an operation implies that there
  are no operation-specific exceptions. Invocations of such an operation
  are still liable to receive one of the standard system exceptions.

ECMAScript 3rd ed doesn’t have any declarations for exceptions.  Java
does, but you need only list checked exceptions (and the Java bindings
for DOM Core inherit from RuntimeExeption).

Given that the IDL is meant to be language neutral though, and there are
some languages where all exceptions thrown must be declared, it makes
sense to require it.  (It is somewhat informative, anyway.)

> What's the purpose of the 'module' block?

It’s used to group declarations together, much like namespaces in C++.
In Java bindings for DOM specs, the names of the modules correspond to
package names.  In the ES binding defined here, they aren’t used.

> Is the idea that DOM Core will define an 'exception' block for 
> DOMExceptions?

Yes, and it does already:

  http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-17189187

Or do you mean for the constants?  The issue I have in the document at
the moment is for associating constants with exceptions.  In that DOM 3
Core section, the ExceptionCode constants are just declared at the
module scope, but in the ES binding the constants are on the
DOMException interface object, and in the Java binding they’re on the
DOMException class.

> For sequence<octet> it would be really nice if we could have a more native 
> representation of a byte array than a UTF-16 string.

Strange, I really should have used sequence<unsigned short> there.
Fixed.

I still am a little unsettled by the special casing of
sequence<unsigned short> for string values.

We could revisit the decision not to use wstring, and just state that
wstrings must be sequences of UTF-16 code units, and that they can
include 0x0000.

> Editorial: you have "which functions, analagously to the" (extraneous 
> comma) in various places.

It’s meant to be a parenthetical comment, like “which functions
(analagously to foo) as follows”.

-- 
Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au
Received on Thursday, 28 June 2007 03:57:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT