- From: Jeen Broekstra <jeen.broekstra@aduna.biz>
- Date: Thu, 15 Dec 2005 11:07:29 +0100
- To: Lee Feigenbaum <feigenbl@us.ibm.com>
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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