xsl-list
[Top] [All Lists]

RE: [xsl] Streaming terminology: Climbing

2014-01-30 04:37:41
Thank you very much Michael!

I really like this:

        A "stack" of ancestor data is maintained 
        as the streaming processor works its way 
        through the document.

I have a few follow-up questions, if I may.

You wrote:

        ... this confuses the role of the context node 
        and the current streaming position.

Would you elaborate on this please? I thought that the context node and the 
current streaming position are one and the same, i.e., context node = current 
streaming position?

You wrote:

        For example the construct

                descendant::x/parent::y

        is climbing, although it does not select ancestors 
        of the context node. It's climbing because it reads 
        information from the "stack" of ancestor data that 
        is maintained as the streaming processor works its 
        way through the document ...

Truthfully, my heart sank when I read that, as it reveals that I still do not 
grasp what "climbing" means. I thought that climbing means "climbing up the XML 
tree." Clearly descendant::x is not a construct that is climbing up the XML 
tree. Are you saying that descendant::x/parent::y is climbing because there is 
a portion of it that climbs up the XML tree, namely parent::y climbs up the XML 
tree?

You finished the above sentence with

        ... and when you're positioned in that stack, your ability 
        to select downwards is constrained.

Would you elaborate on that please? It sounds like a very important concept.

Thanks!

/Roger

-----Original Message-----
From: Michael Kay [mailto:mike(_at_)saxonica(_dot_)com] 
Sent: Wednesday, January 29, 2014 6:50 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Streaming terminology: Climbing

Yes, it's a very useful explanation.

I think your conceptual model that the processor is "positioned just after the 
start tag" is probably helpful to many people but it's worth pointing out that 
it's not in the spec and we try not to over-constrain implementations. There's 
also a glitch in it in that we (deliberately) define has-children() to be an 
inspection construct, and to evaluate this function the processor needs to peek 
just beyond the end of the start tag. (Saxon doesn't yet implement this).

There's also a minor error where you say:

A construct is climbing if, when executed, it yields the context node (self) or 
ancestors of the context node.

Apart from the fact that attribute selection is also climbing (despite the 
name), this confuses the role of the context node and the current streaming 
position. For example the construct

descendant::x/parent::y

is climbing, although it does not select ancestors of the context node. It's 
climbing because it reads information from the "stack" of ancestor data that is 
maintained as the streaming processor works its way through the document, and 
when you're positioned in that stack, your ability to select downwards is 
constrained.

Incidentally, at one time we defined the spec so that as well as retaining "the 
start tags of all ancestors" in this stack, we also retained some positional 
information about the position of each ancestor relative to its siblings, 
allowing match patterns such as match="para[1]". This has been dropped from the 
spec, but it's partially implemented in Saxon, and I have yet to decide whether 
to retain it in some form.

Michael Kay
Saxonica


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--


<Prev in Thread] Current Thread [Next in Thread>