Re: [xml] libxml2 and default namespaces


On Sun, 2005-12-11 at 17:56 +0100, Paul Boddie wrote:
On Sunday 11 December 2005 11:23, Daniel Veillard wrote:
On Sun, Dec 11, 2005 at 02:20:28AM +0100, Paul Boddie wrote:
Perhaps the real issue is whether a namespace set on an element whose
qualified name is unprefixed can be discarded in the serialisation.

  That's just wrong, the error maybe when building the tree because the
namespace declaration was not set to be in scope, but this is a serious

Alright. I'm fairly convinced, subject to a review of the DOM specification, 
that libxml2dom does the right thing in setting the default namespace 
(although it doesn't currently do enough in certain other respects that are 
now being fixed as I write this) and that the serialisation of documents 
produced in the described case is correct.

Thanks must go to both you and Rob for helping me through the thought process. 
Sorry to disturb you with what must seem like trivia!

Don't worry, I don't think this is trivia. I'm happy that this issue
reached the surface once again, since it seems to me still
underestimated by DOM users. I guess the most people using DOM think
that there's no way of how the serialized representation of a DOM tree
might break.

A plain DOM serializer will just close it's eyes and won't try to
change anything what's in the DOM tree. That's fine and wanted
for e.g. editing applications.

If one wants a samantic-safe serialization, then one needs a
namespace-normalization mechanism; although you risk breaking
QNames in element/attribute content on the other hand.

The options here would then be:
1) Close your eyes and serialize the tree
  a) if you know exactly that you didn't create mess in the tree then
     this is OK
  b) be aware that your serialized tree might be broken
2) Normalize namespaces and then serialize
  a) the normalization will try to change prefixes,
     remove/add ns-declarations, in a way that a serialization is
     possible without altering the semantics of the DOM tree
  b) if the DOM is not serializable then the normalization should raise
     an error
  c) be aware that the normalization might break your QNames

If we apply namespace-normalization to your example, then the outcome
would look like:
<href xmlns:ns1='DAV:'/>
i.e. the namespace declaration of 'DAV:' would get a different prefix,
in order to not interfere with the <href> element in no namespace.

On the one hand I use namespace-normalization for small DOM trees,
where the overhead of a normalization doesn't matter; on the other hand,
I just try to be careful and keep the serialized form in the back of my
head when working on a huge DOM tree, where I want to avoid



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]