Re: allow implicitly unbound variables in SPARQL results? (formatting fixed)

Lee Feigenbaum wrote:

> I'd like to add a bit on Elias and my objection to choice 'c'.
> Basically, the results format as it currently stands explicitly makes
> possible multiple ways of processing the results format -- either by
> variable name or by column position, given that the results format
> mandates that the order of the variable names must in each row in the
> resultset must match the order in the header of the result document.
> Option 'c' eliminates the indexed-based approach to parsing the
> results. At the very least, I feel that if the Working Group decides
> on option 'c' than the requirement that variable name order be
> preserved within the resultset should be removed.

I could live with that. It does not make processing any harder in this
variant.

> I must say that I, at least, am not particularly swayed by our 
> requirement for a  bandwidth-efficient protocol. Yes, the collapsed 
> version is more efficient, but only for a particular class of queries
>  (those featuring unbound variables). I would much rather publish a 
> less-efficient yet fully functional XML design along with an
> informative pointer to a much-more efficient binary design then
> attempt what I see as a strange compromise. (The flippant side of me
> wants to point out that the results format would be more efficient if
> it only used one-letter element names, as well.)

True, and perhaps slightly less flippant, the use of a binding element 
itself is not really necessary either:

  <result>
    <bnode binding="foo">bnode1</bnode>
  </result>

carries the same information. There are definitely several ways to 
optimize the XML format, bandwidth-wise. I think the decision here 
though was that we choose a slightly more elaborate format for better 
clarity, aesthetics if you will.

> Regarding the complexity of the XSLT for the collapsed version. While
> I appreciate Jeen's attempts to demonstrate that it is not 
> particularly difficult to write XSLT for the collapsed result format:
> 
> 
> 1) The technique that Jeen uses of remember positions and then 
> comparing current positions with expected names, is not particularly
>  elegant. Obviously, it is not incumbent upon us to produce a design 
> which allows for elegant processing, but this does bother me.
> 
> 2) More importantly, the XSLT as currently in CVS does not work 
> correctly. I am attaching a sample input result format that produces
>  an incorrect and malformed table when used with this XSLT. I would 
> argue that this is due to the added complexity of the collapsed
> result format.

Thanks for pointing this out. Actually I think it's a result of me
trying to adapt the existing stylesheet rather than creating a new one.
I think that a stylesheet that just iterates over all header fields and
for each field retrieves the corresponding value from the result would
be a much more elegant (and much easier!) way to do it.

So I tinkered a bit, and have cleaned up the 'collapsed' stylesheet. It
now processes the result correctly, I think (and is a lot more elegant
to boot, IMHO). It's available again at:

  http://www.w3.org/2001/sw/DataAccess/rf1/sparql-collapsed-to-html.xsl

If nothing else, this whole discussion is a great way for me to get an
XSLT education :)

Cheers,

Jeen
-- 
Jeen Broekstra          Aduna BV
Knowledge Engineer      Julianaplein 14b, 3817 CS Amersfoort
http://aduna.biz        The Netherlands
tel. +31 33 46599877

Received on Thursday, 15 December 2005 10:08:24 UTC