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

RE: adding addressing capabilities to the DOM

  • From: keshlam@u...
  • To: www-dom@w..., "Xml-Dev@Xml. Org" <xml-dev@x...>
  • Date: Fri, 21 Apr 2000 18:29:15 -0400

RE: adding addressing capabilities to the DOM
> It seems to me that Joe is speaking more to the case where the DOM is
> completely in memory.

I admit I'm probably slightly biased in that direction, but I think I'm
keeping the other models in mind. The DOM is only an API; what's behind it
is up to the individual implementation.

> As someone who has implemented a DOM on top of a
> database, I have to agree with Francis here and say that providing a way
to
> delegate responsibility for evaluating XPaths (or other types of queries
in
> the future) into the implementation is vital.

I'm not disagreeing, actually. For performance reasons, it's generally
desirable to push query-type operations as close to the raw data as
possible. But the problem is probably not as simple as it appears at first
glance.

* If you're concerned about performance, you probably want to be able to
store "compiled" forms of your queries. Something could be done with
caching, but something more intelligent could be done under management of
higher-level code.

* What's the basic nature of queries -- meaning simple things like "are the
results presented in document order" -- and what does that imply for how
they mesh with the currently available return types in the DOM?

* Does the result have to be "live", as the existing filtered DOM views are
-- ie, if I relocate or remove a node in my document, does the query result
update itself or do I have to repeat the query to get the new status?

There may be others. I'm not sure that saying "only XPath is supported"
really simplify the query API significantly; seems to me that at best it
allows some of the questions to be swept under the carpet, very
temporarily... and leaves us with a call which is at best a convenience
routine, and at worst may have not-completely-compatable behavior with
whatever the final answer turns out to be.



Note that a stopgap might be doable using existing DOM APIs. It might be
possible to create a Filter class for XPaths, and then special-case the
createNodeIterator/createTreeWalker to recognize that specific filter and
instantiate Traversal objects which perform the XPath query at a lower
level. In fact, you could have a whole subclass of Filters which operate by
translating their queries into database-compatable form, and Traversal
objects which recognize them, issue those queries, walk their results, and
(if necessary) reissue the queries or otherwise resynchronize when the
document is mutated.

One cute possibility about this approach is that the same filter-factory
interface could also produce "normal" filters for evaluating these queries
in DOMs that don't have the internal query engine, so they would still
produce reasonable traveral results (albeit more slowly).

This is one of the directions the Query Editorial Team was investigating,
before it decided that queries weren't well enough understood yet and just
getting a good definition of traversal was going to be difficult enough.
I'm not sure whether there was any consensus on this being a _recommended_
direction, but it's one of the approaches to implementing traversal filters
that we kept in mind. In fact, one of the reasons you can't change filters
in mid-traversal is to enable this sort of architecture.



I do think that having a Query API would be a Good Thing. But I worry that
there are enough design issues here that an off-the-cuff design is unlikely
to make anyone very happy for very long.

______________________________________
Joe Kesselman  / IBM Research



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.