Lists Home |
Date Index |
- From: "Clark C. Evans" <firstname.lastname@example.org>
- To: Pavel Velikhov <email@example.com>
- Date: Mon, 29 Nov 1999 06:36:09 -0500 (EST)
On Mon, 29 Nov 1999, Pavel Velikhov wrote:
> > If you have to "dig" into the contents to figure
> > out which "processing pipeline" the content is
> > placed on then you have effectively elminated
> > all hope of sequential processing. Thus, you
> > need random access to the information stream.
> > And hence, "large" memory requiremens, thus
> > undermining the apparant "simplicity" of SML.
> Well, I don't agree with you on this point. I have been working
> on a streaming query processor for XML for some time, and the
> problem is just not there. Why is it a problem going into the
> element one or two levels deep? Besides the chances that you will
> encode all the information relevant to the query processor into
> attributes is very small. Consider the example above with the
> local schools: what if I want to select all homes that have
> some specific school in their neighborhood? This information
> cannot be encoded in the attributes, since its nested. But I
> can still stream such queries, all I have to do is descend one
> level into each element and the find the school that satisfies
> the condition.
In the case you have mentioned, if the <home> to be presented
exceeds the capacity of the input buffer, then it must be copied
elsewhere until enough information is gathered to accept or
reject it. If the element in question is a top-level element,
and if its children are numerous or large, then a large portion
of the XML stream need be held in storage. In any case,
a large number of allocations/deallocations would occur if
the input buffer could not be leveraged.
What I would do in this case, is make hash values for
the possible schools, and put the hash values in the
attributes -- as this information is intended for
the processor of the information and not for the end-user.
With this information, the memory requirements could be
dramatically reduced since only a small fraction of
the stream would have to be held in memory. Best yet,
the attribute stream can now be discarded even if it
exceeds the input buffer. I hope this explains where
I'm coming from.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)