I know that. We are using keys extensively (mostly to lookup blank nodes).
Still, XSLT processing model is based on XML trees, and not RDF graphs.
It also depends on the output format you want to produce. In our case it is
XHTML which renders the resources and properties (and not triples), so it
corresponds to RDF/XML nesting.
Therefore it's more natural (in our case at least) to be able to simply
invoke
<xsl:apply-templates/>
rather than
<xsl:apply-templates select="key('triples-by-subject-and-predicate',
concat($my-subject, ' ', $my-predicate))"/>
On Wed, Oct 11, 2017 at 12:10 PM, Conal Tuohy <conal.tu...@gmail.com> wrote:
> On 11 October 2017 at 19:30, Martynas Jusevičius <marty...@atomgraph.com>
> wrote:
>
> > TriX is not particularly well-suited for XSLT processing as it's a raw
> list
> > of statements. A nested resource/property structure like in RDF/XML is a
> > more natural fit for the parent/child traversal that XSLT does best.
> >
>
> In XSLT you're not restricted to traversing from parent to child elements.
> The "child" axis is only one of several XPath axes. There's also a very
> common programming pattern in XSLT for traversing cross-references (such as
> IDREF and internal URI references), by using an xsl:key to generate an
> index, and then looking up elements using the key() function. This allows
> you to look up triples by subject, or subject-and-predicate, etc:
>
> <xsl:apply-templates select="key('triples-by-subject-and-predicate',
> concat($my-subject, ' ', $my-predicate))"/>
>
> The value of TriX for graph processing in XSLT is precisely *because* it is
> just a list of statements. That is what makes it easy to process RDF *as a
> graph* in XSLT. Whereas if your dataset is encoded in RDF/XML, it's
> enormously difficult to process *as a graph*.
>
> --
> Conal Tuohy
> http://conaltuohy.com/
> @conal_tuohy
> +61-466-324297
>
