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
