On Wed, Jan 07, 2004 at 06:06:40AM -0500, Rob Richards wrote:
From: "Daniel Veillard" <veillard redhat com>
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.

  They don't. They must not be shown if you implement DOM, similary
they don't show up in XPath or XSLT.

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.

  Sounds a good idea :-)

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.

  I think only editor like processing might be interested in 
XML_XINCLUDE_START/END so if you don't build an editor you should ignore
them (and possibly remove them).
  Post a bugzilla RFE to have a specific flag to avoid XInclude nodes
when using
  xmlXIncludeProcessTreeFlags and xmlXIncludeSetFlags


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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