Re: [xml] redicting parts of trees

Daniel Veillard wrote:

 instead of recreating all the namespace declaration used in the subtree
at the insertion point, then reuse the declaration already in scope at that
insertion point. Example if {"dbk", ""} is in scope at the
insertion point due to an ancestor holding the declaration, then if this
is among the namespace bindings in use by the subtree, do not redeclare
it at the insertion point. Apparently a difference between PHP5 and javascript
implementation of import seems to be that javascript one would reuse the
namespace declaration if defined with a different prefix (hence changing the
prefixes in the pruned subtree), I don't know which smeantic is DOM's one :-)
Few comments on the decisions made in PHP 5 implementation:

There is no standard way to do this, at least none that I could find. This issue had been asked on the php-xml list a few times over the past year and a half so I can tell you why I decided to go the recreate route. Javascript will only reuse namespaces in the top level node. Any namespaces declared in children are not mapped to existing ones once appended. Rather than lead to more user confusion (As namespace questions were asked a lot early on), I decided to go for consistency and have all namespaces recreated, instead of just ones in the children, defined in appended node, preserving the original prefixes. Also why involve more processing to attempt to remap namespaces when the copy works perfectly fine and does not alter the meaning of the document? Other than having to initially explain that the documents meant the same thing (one reusing namespaces and one recreating the namespace declaration), the user questions surrounding this have stopped, so I assume it is a non-issue for them now.

adopting a node...

DOM Core 3 and complex to implement gave it a low implementation priority. While looking at it, however, starting with some simple documents, I ran into issues with IDs - as these needed to be taken into account as well when moving subtrees as at a minimum, the original doc needs to be cleaned up, which got me off the adopting stuff and on the attribute ID tangent (still working on it as time has been short for me lately).

With regard to Kasimier's comments, I agree on the safe method.

imo, an unsafe method should have its own function name or a big warning added to comments for a single function stating that passing the extra parameter(s) could blow up your code if not handled correctly.


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