W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: An import statement for Web IDL

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 30 Jun 2009 03:15:41 +0000 (UTC)
To: Cameron McCormack <cam@mcc.id.au>
Cc: public-webapps@w3.org
Message-ID: <Pine.LNX.4.62.0906300309290.16244@hixie.dreamhostps.com>
On Tue, 30 Jun 2009, Cameron McCormack wrote:
> Cameron McCormack:
> > > I propose that we have an import statement that takes a (possibly 
> > > relative) URL. …
> Ian Hickson:
> > I'd rather we just implicitly said that all IDL files were imported.
> What exactly would “all IDL files” include?

All the IDL files that are supported by the implementation in the relevant 
context. So for instance, in a worker's JS context, all the IDLs from Web 
Workers, some of the HTML5 ones, the XHR one minus the mention of 
Document, etc.

> > and (b) they force a particular file organisation structure on 
> > implementations.
> I don’t think this is the case.  Implementors are of course welcome to 
> split up IDL as they see fit for their build processes.

Then they'd have to strip all the includes also and redo it in whatever 
way is necessary for their environment.

> My main desire is to be able to declare certain IDL fragments as non-
> conforming.  For example, taking this interface from HTML 5:
>   interface HTMLIFrameElement : HTMLElement {
>              attribute DOMString src;
>              attribute DOMString name;
>              attribute DOMString sandbox;
>              attribute boolean seamless;
>              attribute DOMString width;
>              attribute DOMString height;
>     readonly attribute Document contentDocument;
>     readonly attribute WindowProxy contentWindow;
>   };
> Taken in isolation, the names HTMLElement, Document and WindowProxy are 
> undefined.  There needs to be some way of identifying what those names 
> resolve to.

WindowProxy is defined in that very spec (in prose, since it's not 
describable in IDL), as is HTMLElement (in IDL). Doucment is defined in 
the IDL of a spec that HTML5 normatively references (DOM Core). If we say 
that all the IDLs are implicitly imported, the IDL seems unambiguous.

> One way might be to state that the above IDL fragment, even in 
> isolation, is a conforming IDL fragment, but then to define another 
> conformance class (“conforming set of resolved IDL fragments” or 
> something), for which those names do need to resolve to appropriate 
> constructs.  The set of IDL fragments to use could be defined in the 
> HTML 5 spec as prose (identifying all of the fragments in the HTML 5 
> spec, plus the relevant ones for DOM Core/Events/Views/etc. interfaces).

Why can't it just be implicitly all of the IDL referenced?

I guess I don't understand what problem we're trying to solve here. It's 
not like the IDL above is ambiguous; there's only one interpretation that 
I can think of, at least, that is self-consistent.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 30 June 2009 03:16:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC