On Sun, 19 Dec 2004, Jon A. Cruz wrote:
Actually, I think it's a higher priority, as it goes to underlying internal structure. Often converting a namespace-naive program into a namespace-saavy one after the fact can be quite a task. On the other hand, keeping the final goal in mind early on can greatly reduce the work.
Wait a moment. We've been namespace-aware since before the fork.
We store expanded names as qnames using a predefined set of prefixes -- e.g. "{http://www.w3.org/1999/xlink%7Dhref" is represented as the qname "xlink:href". This doesn't depend on the original document's prefixes, which we mostly throw out.
[ Non-predefined namespaces do get unique prefix dynamically assigned to them when they are encountered, and for that we do use the original document prefix if it has not already been assigned. ]
[ Yes, it would have been less confusing if I'd used a different "short notation" for expanded names. It made the transition to namespace-awareness much easier though. ]
SVG was the one exception I made; it uses a bare localName -- e.g. we use "svg" to represent "{http://www.w3.org/2000/svg%7Dsvg". This was to minimize the changes to the codebase at that time; my intent was to come back and change that later. Now is the time...
I'm not really interested in preserving the original document's xmlns mappings, given that DOM1 knows nothing about them, and the namespace-aware DOM2 throws them to the wind; using the DOM2 APIs you can name stuff with any ( namespace, prefix, localName ) tuple you like, regardless of what xmlns attributes are present.
Now, we could still remember the individual prefixes in each repr node, and try to use them when serializing to the extent practical, but that's a cosmetic consieration, not a matter of standards compliance.
[ to implement DOM compliantly we do need to store prefixes somewhere -- but it could be in the DOM node impls, rather than the repr nodes they reference ]
-mental