W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: [WebIDL] remove modules

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 13 Aug 2011 12:33:18 +1200
Message-ID: <4E45C64E.1090906@mcc.id.au>
To: Bryan Sullivan <blsaws@gmail.com>
CC: Marcos Caceres <marcosscaceres@gmail.com>, Arthur Barstow <art.barstow@nokia.com>, Paddy Byers <paddy.byers@gmail.com>, public-webapps@w3.org, public-script-coord <public-script-coord@w3.org>
On 13/08/11 5:38 AM, Bryan Sullivan wrote:
> How would you propose that such a hypothetical new version deal with
> this change?
>
> Take a simple example: the WAC 2.0 Accellerometer API:
> http://specs.wacapps.net/2.0/jun2011/deviceapis/accelerometer.html
>
> The purpose of this question is to see if the actual impact of this
> change (on specifications, and the related impacts on
> implementations) is clear.

Unless the [NamespaceObject] extended attribute is used on a module, 
then the module has no effect on implementation requirements in the 
ECMAScript language binding.  The only thing it provides is a way to 
name interfaces and have them not clash with others the specification 
writer is unaware of.

That brings up a problem: if you have the following IDL

   interface A { };
   module B { interface A { }; };

then we have conflicting requirements for the window.A property.

Do you know if either

   (a) language bindings other than ECMAScript are needed, and
       particular language-specific namespacing/packaging is required; or
   (b) the [NamespaceObject] extended attribute is used in any of these
       specifications?

If neither is the case, then I would say just remove the "module { ... 
};" declarations from the IDL in these specifications.  If some 
interface names currently in modules would clash with others, then you 
should rename them, because they are already conflicting in the 
ECMAScript binding as I mention above.

> On the second point (a WAC extension for modules), how would that be
> defined? If WAC (and OMA) really needed such an extension, why would
> W3C object to it being a part of the Web IDL spec (if it is not used
> in W3C specs then fine, but the universe of Web API specifications is
> larger than W3C...).

It's a maintenance/complexity thing: given we are focusing on the web 
platform here, does it make sense to spend time maintaining a feature 
which is used only in non-web contexts?
Received on Saturday, 13 August 2011 00:34:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC