- From: Lee Feigenbaum <feigenbl@us.ibm.com>
- Date: Sat, 7 Oct 2006 17:49:18 -0400
- To: conor325 <conor@the325project.org>
- Cc: public-rdf-dawg-comments@w3.org
- Message-ID: <OFF8AF3610.22D54472-ON85257200.00776A87-85257200.0077DEE3@us.ibm.com>
public-rdf-dawg-comments-request@w3.org wrote on 10/07/2006 05:20:41 PM: > > thx Lee. > > BTW, does the JSON format have to directly ape the XML form - so that > if the XML form has multiple bindings then the JSON form must too? > The extra binding - or many extra bindings if there are many multiple > assertions - doesn't seem to serve the purpose of JSON which I think > is to be trivial for a client to process? There is no requirement in the DAWG's charter to produce a JSON serialization of results, so it's not really appropriate to speak of what the JSON format did or did not "have to" be. Rather, the editors (including myself) felt that it was appropriate to make the JSON format as predictable as possible, and we felt this would be accomplished if it were as similar as was reasonable to the XML format. <takes off DAWG member hat> As for the triviality of processing, we prefer the JSON format in our browser-based applications of SPARQL due to the lightweight nature of parsing the structures. Instead of wielding an XML parser, the JSON structure requires a regular expression substitution, a regular expression check, and a call to eval() to be in a usable state. Once there, we do find it very straightforward to transform between the SPARQL Query Results JSON format and simpler JavaScript data structures. For example, the transformation which makes the selectValues() form of querying possible in the sparql.js library is nothing more than: selectValues: function (o) { var v = o.head.vars[0]; // assume one variable var values = []; for (var i = 0; i < o.results.bindings.length; i++) values.push(o.results.bindings[i][v].value); return values; } Lee
Received on Saturday, 7 October 2006 21:49:28 UTC