Re: Namespace-aware APIs do not need to suck

On Nov 20, 2009, at 3:20 AM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>> ...
>> I think to have a solid proposal we'd need:
>> A) More methods than just createElement()... a big part of the  
>> concern is using DOM APIs to deal with elements and attributes  
>> created by parsing markup.
> > ...
>
> Obvious additions would be
>
>  Node.expandedName
>
> plus Clark-Notation aware variants of
>
>  Node.getElementByName
>
>  Node.createElement
>
> Would having equivalents for everything in DOM L2 be sufficient, or  
> are you looking for more?

I'm looking for someone to make a proposal that's closer to the level  
of detail needed to make a spec.

>
>> B) Slightly more formal specificiation - a sample implementation in  
>> JavaScript is not easy to read or clear about what details would be  
>> normative.
>> Assuming this aligned with the DOM Core set of methods, then  
>> probably Web Apps WG would be the right venue for such a proposal.
>
> The venue doesn't really matter. What's important is that *if* one  
> of the perceived problems with XML namespaces is the quality of  
> namespace support in DOM, then some group inside the W3C should work  
> on fixing this.

Assuming you or someone else cares enough to push this forward, I am  
advising on how best to advance it.

>
>> Personally, I'm still somewhat dubious of this API. Having to  
>> predeclare all the tags you intend to use is inconvenient and may  
>> substantially
>
> You don't have to predeclare. But if you do you benefit from syntax  
> checking (if you mistype the variable name holding the expanded  
> name, the script will fail early).

If you don't predeclare then it's harder to use than the current DOM.

>
>> increase code size. But it might be nicer if there were predeclared  
>> versions of the Clark notation strings for all standard elements  
>> and attributes. For example if you could write this without having  
>> to predeclare anything:
>> var x = document.createElement(svg.a);
>> x.setAttribute(xlink.href, "http://foobar.com");
>> ... then that would be pretty sweet.
>> ...
>
> That would require hardwiring SVG into the API. I don't think that's  
> a good idea. If we did that, we could also do

It would not require hardwiring SVG into the DOM Core API. It would  
require hardwiring some tag and attribute name constants into the SVG  
API. SVG UAs already have to hardocode all SVG tag names internally,  
so this is not a burden.

>
> var x = document.createSvgElement("a");

If you take this to its logical conclusion, you would have to have an  
extra copy of every DOM method for every "well-known" namespace. That  
seems less elegant to me than providing predefined Clark notation  
strings.

Regards,
Maciej

Received on Friday, 20 November 2009 23:10:29 UTC