Hi, On Tue, 2005-10-04 at 09:03 +0200, Samuel Díaz García wrote: > Thanks for the response to all. > > I solvented the problem using the "recursive function" I exposed (copied > from an old e-mail in the list) and it works fine.
OK :-) > But I don't stand why the default namespace in an element, is not > assumed for the childs and so on. Don't allow us the standard to put > only the namespace in a node? The reason why this is not apparent to you might be the fact, that we are used to look at XML documents, where ns-decl. attributes clearly seem to be the only source for nodes being in some namespace. So it we _edit_ a namespace declaration then this seems to change the namespaces of subsequent nodes. But this is the document representation only - at the API level this looks differently. E.g. using the DOM API the namespace declaration attributes are _not_ relevant for the namespaceURI property of an element or attribute node. Changes to the namespaceURI need to be performed separately for every node. This becomes apparent when one creates some elements in some namespace (note that we don't add any ns-declarations) and serializes the DOM tree into an XML document; if one didn't normalize the document beforehand, which would automatically add missing namespace declaration attributes, then the elements in the XML document end up being in no namespace. So one quickly realizes that ns-decl. attributes were invented to bind nodes to a namespace at the XML document level; at the API level every node has its own namespaceURI. However, currently ns-decl. attributes _are_ needed while working on a DOM tree; this is due to QNames: if an attribute holds a QName value, then we need to _manually_ assure that a ns-decl. attribute is in scope for it, otherwise we would loose the namespace of the QName when the tree is serialized to XML. Hopefully in the future, with the advent of data type annotations, one will be freed from this burden; if the processor _understands_ that a specific value is a QName and not just some characters, it will _know_ its namespace and will be able to automatically add ns-decl. attributes when the document is normalized. With Libxml2 this looks a bit different; Libxml2 depends on ns-decl. attributes being existent in its DOM-like tree, because they represent the sharepoint of a node's namespace information. By the way, have you already considered to use XSLT to fix your XML documents? Regards, Kasimier _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
