[XML-SIG] DOM API

[Ken MacLeod]

Paul Prescod <paul@prescod.net> writes:

> Greg Stein wrote:
> > 
> > XML 1.0 *defines* PIs. That is very different.
> 
> Okay, so you agree that PIs are part of XML document instance
> data.

Why not have an option in the DOM tree builder or a method on the
document and element nodes to remove PIs?  Very similar to the
normalize() method for joining consecutive text nodes.

The combination of SAX filters and a SAX DOM tree builder allows one
to choose (write a filter for) any type of tree you want to see.

It seems very important to me that the tree model itself be able to
hold every type of node an application may need (including even
non-DOM, non-XML nodes), but it is also important to be able to
constrain the nodes in a tree to _just_ those nodes an application
wants.


Re. lightweight API, I haven't seen qp yet so I'm not exactly sure
what it's API is.  When I think of a ``lightweight'' XML tree I don't
think of an API, per se, at all.  A lightweight XML tree to me is a
nested tree of XML objects.  For example, an element would have
attributes name, attributes (a dictionary), and contents (a list) and
a PI would have attributes target and data.

The core objects are in classes, but there are no (or no strong need
to have) methods in the core classes.  Methods are added to the core
classes by ``extensions''.  Extensions are things like normalize, get
elements by tag name, get elements by id, visitors, filters, writers,
converters, etc.

The effect, though, is that outside of calling methods to act on the
tree all you're doing is working directly with the XML objects and
their attributes.

This pattern works well on any type of tree that has both complex data
types and many categories of functions that may be applied to the
tree, such as 2D and 3D graphics, directed graphs, networks, component
hierarchies, etc.

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us