- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 13 Aug 2011 12:33:18 +1200
- 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:06 UTC