- From: Kartikaya Gupta <lists.webapps@stakface.com>
- Date: Sat, 29 Nov 2008 15:10:13 +0000
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: public-webapps@w3.org
On Sat, 29 Nov 2008 13:16:07 +1100, Cameron McCormack <cam@mcc.id.au> wrote:
>
> Kartikaya Gupta:
> > I would prefer not hard-coding a package prefix. The implementation I
> > just finished writing basically auto-generates a bunch of stuff from
> > the DOM IDL files. Since it worked pretty well, we decided to create
> > IDL files for some other proprietary interfaces so that we could
> > auto-generate stuff for those interfaces too in a consistent manner.
> > Those interfaces aren't in the org.w3c namespace, and hard-coding that
> > prefix would make things more complicated. (My current implementation
> > uses the [Prefix="..."] xattr from an earlier draft, which I'm fine
> > with changing to Package or JavaPackage or whatever, as long as it
> > allows specifying things outside of org.w3c as well).
>
> OK. The hard coded prefix approach I suggested above would still have a
> mechanism for overriding that. For example:
>
> module dom { interface Node { ⦠}; };
>
> module svg { interface SVGElement : Element { ⦠}; };
>
> [Prefix=org]
> module acme { interace NiftyElement : Element { ⦠}; };
>
> could result in interfaces org.w3c.dom.Node, org.w3c.dom.svg.SVGElement
> and org.acme.NiftyElement. [Prefix] could take a scoped name, and then
> language bindings other than Java could define how that module name with
> the prefix is mapped to the namespacing mechanism of that languages
> (changing to camel case, or whatever) if needed.
>
> Would that work for you (and Lachy)?
Works for me.
Cheers,
kats
Received on Saturday, 29 November 2008 15:10:51 UTC