xsl-list
[Top] [All Lists]

Re: [xsl] Streaming terminology: Climbing

2014-01-30 05:10:02

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?

No. If you do

<xsl:for-each select="ancestor::*>

it changes the context node (to somewhere earlier in the document) but it 
doesn't change the 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."

Intuitively, yes, that's why we chose the name. But intuition doesn't always 
give the right answer.

But I prefer to think in terms of permitted navigation paths (rather as we drew 
them in the complex diagrams of the 2010 draft, see for example

http://www.w3.org/TR/2010/WD-xslt-21-20100511/#streamability-choice-and-repetition

Essentially the permitted navigation paths allow

C* D? A*

where C is a child step, D is a descendant step, and A is an attribute or 
ancestor step.

This grammar can be defined by a finite state machine, and the states of this 
machine can be labelled "striding", "crawling", and "climbing"; "climbing" is 
the state that is reached after an A step, so any path that includes one or 
more A steps takes you to a climbing state.

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?

Yes, that's essentially what I've been saying in different words.

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.

I thought your slides expressed that rather well. If the streaming position is 
at a given node N, then information about the ancestors of N is available from 
the stack, but information about the descendants of the ancestors of N isn't 
available: either these precede N, in which case they have been forgotten, or 
they follow N, in which case we haven't got to them yet.

Michael Kay
Saxonica

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>
--~--



--~------------------------------------------------------------------
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>