Lists Home |
Date Index |
- From: Paul Tchistopolskii <firstname.lastname@example.org>
- To: Eric Bohlman <email@example.com>, Oren Ben-Kiki <firstname.lastname@example.org>
- Date: Mon, 29 Nov 1999 15:22:26 -0800
> As I see it, you'd need a way of giving names to path expressions and
> their result sets, and a way of making one path expression conditional on
> the success of another. Thus a path expression that goes down the
> conceptual tree along the child:: axis, then back up the tree along
> Ancestor::, and then sideways along following-sibling could be replaced
> with three child::-only path expressions that would have to match in
> sequence (though not the same order as they would appear in the full XPath
> expression), each of which would "squirrel away" the conceptual nodes that
> matched. The idea is to limit the "running storage" required to a stack
> of element names encountered along the current branch of the conceptual
> tree and the text content of the current element (along with any
> squirreled-away data).
To me the most critical thing in streaming XML processing
is do we allow 'look-forward' rules or all of our rules are
'look-backward'. ( Yacc ).
Lets look at 2 'rules'.
1 "If B has parent A" ...
2 "If A has a child B" ...
They look very similiar, but actualy (2) requires DOM
*or* it requires very tricky conversion of (2) into set of
rules of form (1) - possible, but ... it's not a good task
for a thin client, I think.
Even it is possible to make that tricky transformation
of 'look-forward' rules, I think that for the sake of
streaming ( efficiency and embeddability) , the 'basic'
streaming API should use only 'look-backward'
( or 'look-up the tree' ) rules.
So far I think everything was more or less OK with yacc
for long years, so such a limitation is already tested
by many applications.
> An interesting question is whether a full XPath expression could be
> automatically decomposed into a sequence of "sequential-path" expressions.
I think this problem is comparable with converting
look-forward rooles to look-backward rules.
I would better not to support look-forward rules at all in
the core API. If there would be another layer, doing such a
magic - why not?
PS. I was wrong saying that SXSLT should be easy to
write - it could be streaming. I was estimating 'just'
simplified XT. I was not brave enoght ;-) No big
inventions there at the moment, I think.
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 unsubscribe, 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)