xsl-list
[Top] [All Lists]

Re: [xsl] I beseech thee, please give me intuition on XSLT Streaming

2013-09-06 12:17:37
Yes, this is a serious problem. We are acutely aware of it on the WG. We spent 
the last WG meeting trying to apply the streamability rules to some simple 
examples, and they are very hard to apply by hand. Yet at the same time we want 
to don't want to reduce the scope of what is streamable just to make the rules 
simpler.

The simplest rule of thumb is that a streamable template is only allowed to 
make one downward selection. So you can select the Title, or the Author, but 
not both. If you want both, there are ways of doing it, but you can't simply do 
what your example does and ask for the Title first and then the Author, because 
they might not appear in that order (and they might be gigabytes long: just 
because elements have nice familiar everyday names like Title and Author 
doesn't allow us to make any assumptions about what they might contain).

The simplest way around the "one downward selection" rule is to use your one 
downward selection to make a copy of a subtree:

<xsl:variable name="thisBook" select="copy-of(.)"/>

and within the copy you can do any navigation you like. But you can only make a 
copy of a Book if the Book fits in memory.

Some of us are hoping that the solution to this problem might lie in tools: 
tools that explain to you why your code is not streamable. 


On 6 Sep 2013, at 17:43, Costello, Roger L. wrote:

Hi Folks,

... motionless ... sweep ... free-ranging ... group-consuming ...

Those are some of the terms used in the XSLT specification for describing 
streaming.

Ouch!

I am having a hard time slogging through the explanation of XSLT streaming. 

Surely there are some simple intuitions regarding the kind of XSLT/XPath code 
that is (isn't) valid when doing streaming? 

I seek simple rules-of-thumb that will guide me in writing XSLT/XPath code 
for streaming. 

Can you provide such intuitions? Can you provide simple rules-of-thumb?

For example, I have found that it is valid to iterate over each Book and 
output its Title:

<xsl:mode streamable="yes" />

<xsl:template match="BookCatalogue">
       <Books>
           <xsl:iterate select="Book">
               <Title><xsl:value-of select="Title" /></Title>
           </xsl:iterate>
       </Books>
</xsl:template>

But it's not valid to output both Title and Author:

<xsl:mode streamable="yes" />

<xsl:template match="BookCatalogue">
       <Books>
           <xsl:iterate select="Book">
               <Title><xsl:value-of select="Title" /></Title>
               <Author><xsl:value-of select="Author" /></Author>
           </xsl:iterate>
       </Books>
</xsl:template>

Why?

I have no intuition on why the first is valid and the second is invalid.

No doubt somewhere in the XSLT specification there is some precise rule which 
explains why.

I'll never remember all the rules. 

But if I have some intuition to guide me ... ah, that will last a lifetime.

So what is the intuition behind allowing access to one child element but not 
two?

However, I am seeking more than just intuition about that specific example. I 
am seeking intuition about writing XSLT/XPath code in general for streaming. 
Can you provide an intuition so that as I write code I can think: 

      Well, I don't know the specific rule in the XSLT 
      specification, but from my general intuition 
      about streaming I know that this code is (isn't) 
      valid for streaming.

/Roger



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