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(_dot_)honnen(_at_)gmx(_dot_)de
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On 21.03.2017 11:44, Martynas Jusevičius martynas(_at_)graphity(_dot_)org
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.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--