Re: An import statement for Web IDL

On Jun 29, 2009, at 11:26 PM, Ian Hickson wrote:

> On Mon, 29 Jun 2009, Maciej Stachowiak wrote:
>>
>> It would be nice if we could find a way to make things more rigorous
>> with a mechanism that's convenient to both spec writers and browser
>> developers.
>>
>> On possibility: we could consistently use modules and have a way to
>> import by module name, a la Java. Specs could import other modules
>> wholesale with prose or an IDL fragment at the top of the document.  
>> We
>> could recommend that non-W3C spec specs should use "reverse DNS"  
>> style
>> module prefixes to avoid the possibility of collision.
>>
>> This makes the name binding more rigorous than filename-based  
>> includes
>> and should not overly get in the way of implementations or specs.
>
> I would rather have just one module for all of the Web platform,  
> since at
> the end of the day there's only one namespace in JS.

If I were designing things from scratch, I would want to take this  
approach. However, the DOM specs already have their own module names  
and I don't think it's worth changing them. Reserving one particular  
module for all new W3C specifications seems reasonable, but I'm not  
sure it's better than one per spec.

The point of using modules for this at all is to avoid non-W3C  
specifications accidentally or intentionally clashing with the names,  
though on further consideration, it seems like this would cause problems

> However, I do think it'd be nice to have tools to help us check the  
> IDL.
> Could we have a tool that just scans the textContent out of <pre>  
> elements
> with class=idl, or something? We could give it the URLs of all the  
> specs
> being developed, and every hour or day or something it could try to  
> fetch
> all the specs, check that the IDLs still make sense, and if anything  
> bad
> happens, post an e-mail to some list we all subscribe to.

Something like that seems like a good idea.

Regards,
Maciej

Received on Tuesday, 30 June 2009 07:58:45 UTC