Lists Home |
Date Index |
- From: Paul Janssens <firstname.lastname@example.org>
- To: email@example.com
- Date: Fri, 26 Mar 1999 09:43:06 +0100
A simple solution would be to serialize using a PN like format for your
file and have the arrity of each node in the file. It's slower than
having an offset table per node, but faster when inserting or deleting
as the data is almost utterly context free.
If this is too slow, you migh add offset tables per entity-node,
but'you'll have to update these when inserting or deleting, working up
the parent chain.
The first is better for authoring, and the second for querying I'd say.
Paul Janssens - firstname.lastname@example.org
Stephen D. Williams wrote:
> This is not what I meant.
> XML has mechanisms to store binary data as characters using all the standard
> What I'm talking about is using data that is structured in a directly
> addressable way (think pointers, arrays, indexes, offsets) to represent the
> structure and content of an XML tree. My actual proposal is a bit more
> complicated than that because I want other types of optimizations for in-memory
> processing, but that is one of the roots of the idea. In other words, after
> loading the tree would be directly addressable (SAX or DOM) without any parsing
> (or very limited steps). A typical server might in fact support both XML and
> XMLb queries and responses.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)