- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Wed, 09 Jul 2008 14:37:46 +0200
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: public-webapps <public-webapps@w3.org>, Cameron McCormack <cam@mcc.id.au>
Moved from public-webapi to public-webapps. Original issue raised here: http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0053.html (forgot to change the address to public-webapps, resending to correct list. Sorry for duplicates) Lachlan Hunt wrote: >> * It's not clear which IDL, if any, is being used when defining the >> DocumentSelector and ElementSelector interfaces. For example, the DOM >> Level 2 Core specification has a normative OMG IDL set of interface >> definitions, with normative text that says that OMG IDL is being used. >> I see no such normative text here, which I assume is a simple oversight. > > This issue has not yet been addressed. The spec now defines: | The IDL used in this specification uses the syntax defined in Web IDL | [DOM-BINDINGS]. >> * I don't see any indication of what the language bindings for this >> IDL should look like in languages which do not support function >> overloading based on number of arguments and do not allow functions >> with variable numbers of arguments. If it has been decided that no >> one is ever going to implement bindings for this specification in such >> a language , it might be good to explicitly say so in the >> specification so that it's clear that the problem has been >> considered. Another possible solution is to take the approach taken >> in other existing DOM specifications and tack "NS" onto the end of the >> name of a namespace-aware version of a method that is also available >> in a non-namespace-aware version. If the intent is to indicate that >> the bindings in some languages may allow omitting the second argument, >> I think that should be done via some mechanism that doesn't look like >> normative IDL. I would prefer to address this issue in the IDL, but I'm not yet sure how to fix it. The intention is for the methods to be overloaded, and for implementations that don't support method overloading, then the author will need to pass null as the NSResolver. Cameron, is there or will there be some way to deal with this issue in WebIDL? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Wednesday, 9 July 2008 12:38:25 UTC