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

Re: Fw: [SML] Streaming XML processing. ( Whether to support Attributeor

• From: Paul Tchistopolskii <paul@q...>
• To: Eric Bohlman <ebohlman@n...>, Oren Ben-Kiki <oren@c...>
• 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?

Rgds.Paul.

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:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Fw: [SML] Streaming XML processing. ( Whether to support Attribute or not? )
    • From: Joe Lapp <jlapp@w...>

• References:
  • Re: Fw: [SML] Whether to support Attribute or not?
    • From: Eric Bohlman <ebohlman@n...>

• Prev by Date: Re: [SML] Whether to support Attribute or not?
• Next by Date: RE: [SML] Whether to support Attribute or not?
• Previous by thread: Re: Fw: [SML] Whether to support Attribute or not?
• Next by thread: Re: Fw: [SML] Streaming XML processing. ( Whether to support Attribute or not? )
• Index(es):
  • Date
  • Thread