Re: output-xslt good enough for sort objective?

Dan Connolly wrote:
> Dave's message on fromUnionQuery[11Apr ] included:
>   output-xslt  URI of xslt document to apply on XML output (0-1)
> 
> I think Andy's service does that too... yes...
>   http://sparql.org/query.html
> 
> And so does zparqler...
>   http://demo.asemantics.com/zparqler/
> 
> That looks like critical mass. Kendall, please think about
> including that as you're drafting the protocol.
> 
> Does anybody think it's a bad idea?
> 
> I think it's important that we consider this before we close
> the sort issue. XSLT has some sorting capabilities. Should
> we just tell users to use those for the first version of
> sparql?

Speaking for my own service, the XSLT transform is applied by adding the XSL 
stylesheet declaration to the usual results format and sending it back.  So 
it's applied client-side.

> 
> For the "give me the most recent 10 articles" use case, it's
> perhaps somewhat inefficient in the server... the SPARQL
> ending would spit out all the articles and the XSLT would sort them and
> perhaps truncate them. But to the client (and the network)
> it looks just the same.

In the case of my service, the impact on the network is huge - all the results 
are transferred, then sorted, then truncated.  It does not look the same to 
the client.

Some problems arise with placing the sorting as an transformation of the XML 
results:

1/ SORT-LIMIT-CONSTRUCT makes sense for an RDF graph of top 10 most recent 
articles.

2/ Sorting would be XML-defined, whereas sorting after solution generation but 
before serilization is dependent on RDF, so query processors able to handle 
extra datatypes could not export that capability to sorting as it would need 
that capability in the XSLT processor as well.  And there is no way to define 
an (arbitrary) consistent ordering to sorting unlike things e.g. literals and 
URIs.

3/ Interactions between sorting in the protocol would need worked out if ever 
there is both.  c.f. dataset specification except the different sorting 
mechanisms are already different.

Stepping back ...

I suggest that the primary role of the protocol is to transport query requests 
to a server and transfer the results back.  It is the role of the query 
processor (and hence the QL) to generate and manipulate the results, result 
sets included.  This is why I don't think DISTINCT, LIMIT and SORT have a 
place in the protocol - they happen before serilization.


Allowing XSLT to be applied is useful for the creation of presentation but 
using that as the means to manipulate results breaks the separation, so will 
lead to complex interactions (e.g. sorting twice, sorting after limit applied) 
now or later.


So "OK" to have having an XSLT parameter but "no" to saying that meets the 
sorting requirement.

> 
> Hmm... it would be nice to have output-xslt-params too,
> so that the same bit of XSLT could be re-used with different
> variable names and such.

This is a mapping from result set vars to XSLT positional parameters, right?

Just a thought but isn't this close to do mapping that ought to be in RDF 
space as being semantically the same information?  i.e. shouldn't we promote 
this as RDF data integration or even getting results in RDF (CONSTRUCT or 
SELECT) ad mapping in RDF with, say, a rule?

	Andy

> 
> [11Apr ]
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2005AprJun/0054.html
>

Received on Thursday, 14 April 2005 19:28:35 UTC