MenTaLguY wrote:
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.
Yes, I was aware of that. Hence my use of the term "namespace-saavy" instead, implying more complex handling.
[SNIP]
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.
Perhaps. Well, it's correct as far as compliance goes, but it's more than just purely 'cosmetic'. I have hit situations where mixed prefixes come up. Depending on the context, there are a few different things to do. One is to normalize all prefixes. I've done this myself in a pre-processing stage of one system. Another is to just keep things as-is.
I'll have to pour through the current code looking for how things might need to be tweaked. In the long run, I'd consider mixed prefixes under 'not losing user information', and thus a good thing to do.