[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: DOM or SAX: Sense and Sensibility

• To: Michael Brennan <Michael_Brennan@A...>
• Subject: RE: DOM or SAX: Sense and Sensibility
• From: bob mcwhirter <bob@w...>
• Date: Wed, 07 Nov 2001 23:30:35 -0500 (EST)
• Cc: xml-dev@l...
• Delivered-to: xml-dev@m...
• In-reply-to: <D7155AD41ECFD511AF4A00B0D0202CB51DFA64@m...>

> I've been eyeing the dom4j, SAXPath, and Jaxen stuff with great interest,
> lately. I had been thinking along similar lines of Jaxen when I became aware
> of it. Currently, our core platform is based on Microsoft technologies, so I
> can't use this stuff internally. But this notion of registering a handler to
> match subtrees based on XPath is very interesting. 


Currently, it's not full xpath, but a more basic XSLTish Pattern binding
per handler.  Which can be more deterministic.  (Else, you might have
multiple handlers for a single sub-tree, potentially causing problems.
Though we hope to one day support arbitrary xpath location-paths bound
to ElementHandlers).

> Using XPath as the glue between object models that can support an
> infoset abstraction is also very interesting. We commonly load XML
> into a DOM just so we can leverage XPath.

While an OM is not strictly needed, *something* must be behind the
Navigator (the InfoSet adaptor) that can provide roughly random access
to the InfoSet properties.  Thus, I can't really see a bare-bonds
SaxNavigator in the works.  Some flavor of state-retaining OM will
be needed.

> We use tools for mapping XML elements/attributes to internal data structures
> and functions using XPath expressions. It would be great to have that same
> abstraction and ease of implementation without having to load a DOM to do
> it. (I've also advocated exposing our own data structures via XPath, but I'm
> a lone voice in the wilderness, here.)

A generic ObjectNavigator is certainly possible within Java, using
reflection to translate object properties to aspects of the InfoSet.
Someone, somewhere is working on it.  Dmitri of apache.org also has
objectified wrappers to make any JavaBean look like a DOM Document,
which could then be adapted to Jaxen using the normal DOM Navigator.

It all just depends on how many layers you want.

> Is anyone working on any XSLT implementations that work with Jaxen? That
> would be very cool.

I've toyed with the idea, but right now, I don't have the time, and
I think it'd be difficult to dethrone Xalan, due to its current mindshare.

There *is* hearty interest in a Jaxen-based XQuery implementation,
to allow queries across multiple documents of heterogenous object-models.
Join across DOM, JDOM, EXML, and dom4j documents in a single query.
Dunno how useful that truly is, but conceptually, it's certainly
possible when dealing only in terms of the InfoSet, and ignoring
the actual implementation.

Note: The Jaxen Navigator currently isn't a *full* adapter of the
InfoSet.  We'll probably add whatever is needed as we progress.  We
are slightly limited in that some of the underlying object-models
don't necessarily support the complete InfoSet, and we can't simply
devine or synthesize the responses.  This is especially prevelent in
the 'fringe' cases, where we're adapting JavaBeans to the InfoSet.

	-bob

• References:
  • RE: DOM or SAX: Sense and Sensibility
    • From: Michael Brennan <Michael_Brennan@A...>

• Prev by Date: Re: DOM or SAX: Sense and Sensibility
• Next by Date: Re: DOM or SAX: Sense and Sensibility
• Previous by thread: RE: DOM or SAX: Sense and Sensibility
• Next by thread: RE: DOM or SAX: Sense and Sensibility
• Index(es):
  • Date
  • Thread