Re: output-xslt good enough for sort objective?

Bijan Parsia wrote:
> On Apr 16, 2005, at 10:24 AM, Kendall Clark wrote:
> 
>> On Thu, Apr 14, 2005 at 08:28:27PM +0100, Seaborne, Andy wrote:
>>
>>> result sets included.  This is why I don't think DISTINCT, LIMIT and 
>>> SORT
>>> have a place in the protocol - they happen before serilization.
>>
>>
>> FWIW, in the latest drafts (of spec, WSDL and schema files), these are
>> not in the protocol. Just FYI. (And I have no plans to add them back.)
> 
> 
> Sorry to be responding to the wrong message but I don't understadn 
> Andy's argument. Conneg (in general) can happen before serialization 
> (and may have to :)), but seem perfectly part of the protocol. As long 
> as DISTINCT, LIMIT, and SORT come in, conceptual, "before" they have to 
> be applied, it seems fine.

Content negotiation is about transferring the results of the request back to 
the requestor and hence fits with the split I outlined.

> 
> Oh. hmm. I guess, conceptually, the output-xslt comes after 
> serialization. but does it have to implementationally?

yes - applying XSLT would have to come after serialization.  Maybe even in the 
client when an XSLT stylesheet is applied.

An SPARQL implementation can do anything it likes providing it achieves the 
correct results - it can reorder query processing if it can achieve 
efficiency.  That would seem to be outside the spec though.

Of course, XSLT would sort the serilization, not the results of the query so 
may come up with different answers even on XML-encoded results.

	Andy

 > I mean, ok,
> initiate, perform query, serialize, sort could be nasty 
> implementationally, but as long as you *know* what's happening in time 
> to actually *do* initiate, perform, sort, serialize...isn't that ok?
> 
> Sorry not to dig back.
> 
> Cheers,
> Bijan.
>

Received on Saturday, 16 April 2005 16:37:14 UTC