- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Oct 2009 10:27:41 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
On Thu, Oct 1, 2009 at 2:13 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > Jonas Sicking wrote: >> >> On Wed, Sep 30, 2009 at 11:26 PM, Julian Reschke <julian.reschke@gmx.de> >> wrote: >>> >>> Jonas Sicking wrote: >>>> >>>> ... >>>> I'm not actually a big fan of this proposal. Experience with >>>> namespaces in XML has showed (at least to me) that namespaces are too >>>> complex for authors to understand. The most recent example of this was >>>> the discussion on RDFa+HTML where it was clear that even the experts >>>> that developed RDFa thought of nodes as receiving their meaning from >>>> their nodeName rather than from their localName+namespaceURI. >>>> ... >>> >>> Pointer? >> >> This is one example: >> >> http://lists.w3.org/Archives/Public/public-html/2009Sep/0923.html >> >> But really, the whole thread is filled with missunderstandings about >> how namespaced nodes in the DOM work. > > Yes, I agree that the way namespaces work in DOM, and the way L1 and L2 > differ, are confusing. That's a problem of DOM though, not of XML namespaces > in general. I guess you could argue that it's the combination of XML Namespaces + DOM that makes things complex, not XML Namespaces in itself. I don't necessarily buy that, but even if I did, unless you are proposing to do away with DOM, this doesn't really affect the case for if XML Namespaces should be added or not. > Also, dispatching on nodeName is entirely sane if you need to be able to run > with DOM Level 1. How so? An element with nodeName "foo:hello" you have no idea what meaning it has, unless you also know which namespaceURI it's in. >> ... >>> >>> Not sure what you're comparing here. As far as I can tell, there is no >>> proposal here to use prefixes (a la qname or curie) in content. >> >> Are you asking just in relation to the second of my paragraphs above? >> I don't understand the question if it's in relation to the first one >> as well. >> >> Assuming it applies to the second: >> >> One of the problems with namespacing a'la XML Namespaces is that an >> objects identifing name isn't a single string, it's a tuple. Everyone >> has to lug around two separate values, localName and namespaceURI. > > No, that's an API problem. There are other APIs that use expanded names as > identifiers. See above. I don't understand this argument, unless you are proposing to do away with DOM? >> (Many times implementations have to lug around three values, >> localName, namespaceURI, and prefix). >> >> RDF has not chosen to use this. Instead it concatenates the expanded >> prefix together with the localName-esq value in order to form a single >> string. Each part of an RDF triplet, subject, predicate and object, is >> identified by a single string (though in the case of object there's >> additionally a datatype). The triplet does not consist of 3 string >> tuples. >> ... > > But that's because RDFa is a notation for RDF, which uses URIs, not > (namespace,localname) tuples. Ok, might be that the tuples complexity was removed in RDF rather than RDFa. The point remains that the RDF community decided that the XML Namespaces namespaceing mechanism was not a good solution for them. >> ... >> However the proposal from microsoft still uses tuples of strings to >> identify element and attribute names. >> ... > > There's a well-understood way to map these tuples to simple strings, and > back, so again, this is only an API problem. It's also a performance problem. If we store a single string to identify the localName+namespaceURI tuple, that means that we have to parse and split that string into its localName and namespaceURI parts *a lot*. Every time a CSS selector is matched against a node, every time someone calls .localName from the DOM, every time a node is created. I'd say that selector matching would get a couple of orders of magnitude slower if we had to do that. Not quite as much for the other operations, but possibly one order of magnitude there. At least in Gecko. / Jonas
Received on Thursday, 1 October 2009 17:28:35 UTC