Re: [xsl] Streaming and grouping in XSLT 3.0

Subject: Re: [xsl] Streaming and grouping in XSLT 3.0
From: "Martynas Jusevičius martynas@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 21 Mar 2017 11:38:22 -0000
Thanks Martin. That's a start :)

As for the reason we want to use streaming, I guess the answer is both:
- loading external documents such as
http://dbpedia.org/resource/Copenhagen might result in large data
volumes. Right now we are processing them in memory, but we are
running out of it (not using high-end hardware), and the end-user
experiences a noticeable delay since it is a run-time transformation.
I think streaming could help address both of these issues.
- many RDF triplestores/frameworks support streaming IO, which is
becoming increasingly important when used with IoT devices etc. Our
software provides UI over RDF data, and it will become a bottleneck if
streaming is not supported. But it is also based on XSLT which we
would like to continue using :)

Martynas

On Tue, Mar 21, 2017 at 12:20 PM, Martin Honnen martin.honnen@xxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On 21.03.2017 11:44, Martynas JuseviD
ius martynas@xxxxxxxxxxxx wrote:
>
>> Now my question is, how do I even begin analyzing the streamability of
>> this approach in XSLT 3.0? I guess my main concern is that such
>> grouping would not be streamable, but maybe there are other solutions?
>
>
> As the stylesheet uses keys/Muenchian grouping it is true that keys can't
be
> used with streaming in XSLT 3.0. However a
>   <xsl:fork>
>     <xsl:for-each-group select="*[@rdf:about]" group-by="@rdf:about">
> is streamable as far as I understand it.
>
> On the other hand your post has not made it clear to me whether you want to
> use streaming XSLT 3.0 because the XML input is so huge that the normal
XSLT
> 2.0 processing with an in-memory tree built first does not work (which is a
> use case for XSLT 3.0 streaming) or whether somehow your input is streamed.

Current Thread