From: "Daniel Veillard" <veillard redhat com>

On Wed, Jan 07, 2004 at 12:36:59PM +1100, Malcolm Tredinnick wrote:
On Wed, 2004-01-07 at 12:05, Rob Richards wrote:
After you have created your tree and done any validation you require,
you can ignore those nodes.

It would be inconvenient to automatically drop them from any created
tree, since I have more than once come across situations that need to
know when they are leaving the main document and entering some XIncluded

  Well ... on the other hand that's the only way to know that a document
is the result of some XInclude processing and keep track of the fragments.
Simply xmlUnlinkNode/xmlFreeNode them if you don't need them.
  Now if they ended up being processed as normal node, that mean that
there is a tree traversal algorithm broken somewhere...

My first inclination is to unlink and free all of these nodes after the
xinclude processing.
I guess the real question is how do these nodes relate to a dom
implementation written against the W3C specs.

This dom implementation is the re-written dom extension for PHP 5. An
xinclude processing method off the document interface was recently added
which now means we have to deal with the XML_XINCLUDE_START/END nodes which
up until then werent handled as they could never exist within the tree.
Personally I could go either way (removing or leaving them in), but as this
isnt an interal use implementation, I'm trying to get it to do what it
should do rather than what I want it to do :) Unlike the last dom
extensions, we are trying to get this one right form the start so we dont
end up with a mess like the last one.

Not sure what you mean here :
  Now if they ended up being processed as normal node, that mean that
there is a tree traversal algorithm broken somewhere...

For example, after an xinclude procssing, I grab the children of a node
which returns a nodelist that now contains XML_XINCLUDE_START/END nodes in
that list (assuming I didnt remove them). Are these nodes supposed to be
skipped and not returned in the list (which then I ask how would one even
get access to these nodes via dom) or if they are returned, what type of
node are they returned as (Element nodes which means they implement the
Element interface or an interface which extends the dom specs with a few
custom methods/properties just for the start/end nodes?). And if they are
returned then that would mean it would be up to the end user to have to
explicitly test the node type so they could then ignore them.



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