xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mosiewicz <m...@interdata.com.pl>
Subject Re: SAX
Date Sun, 14 May 2000 12:39:13 GMT
Stefano Mazzocchi wrote:
> [...]
> When you want to store XML data and do a bunch of querying on top of it,
> you need a read DBMS which is able to index it's XML content is such a
> way that XPath or XQL queries are created _without_ the overhead of
> parsing the entire XML structure.

Just one thing I have forgotten to comment here. You are absolutely
right, that the content producer is not necessary a parser. In fact
there might be different content producers. Possibly those that make a
use of indexed storage. In some cases it would be wise to implement a
database storable DOM structure, and make a use of passive API. But I
emphasise that this method is bound to passive API. But we've got two
different methodologies - one that is pulling data from some content
storage, and one which is pushing data to content consumers.

I'm just pointing that the second method could be possibly optimised to
make a better use of active API, i.e. of method that is pushing content.
But you seem to prove that it's not necessary, becouse if we can't do
something better using active API, let's just back up to passive.

But here you ommit the fact, that sometimes active API may be suited as
good as passive for executing only those fragments of producing code
that are necessary. And what is important - sometimes it can do it
better than passive api becouse data production and consumption may be
better parallelized.

Note that an XML document have some interesting properties. One of them
is that it groups an ordered tree of elements. There is a whole class of
document transformations that is bound to natural source data order
(like presentation layer), and such transformations can be better
implemented with active API, cause document producer can be more
effective in providing data in natural order, cause in case of active
API moving to next element is as easy, as just proceeding to the next
line of code.

Anyway, the bottom line is that I'm talking about improvements in SAX
API to extend the number of cases when it can be better than pulling

-- Mike

View raw message