W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

JSON results format document

From: Paul Gearon <pgearon@revelytix.com>
Date: Wed, 31 Aug 2011 21:39:22 -0400
Message-ID: <CAOQ8B2FhvKy4jFTXdpz2UaO541cagpfwVP=dhO+VD2uxNzx3yw@mail.gmail.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Hi,

Recently I've had cause to work with the JSON results format, and I
noticed a couple of things about the example in section 5.

- The first binding should contain the variable "mbox" bound to a
literal with a value set to an empty string. This variable has been
skipped.

- The first binding for the variable "blurb" is to a literal with a
datatype of rdf:XMLLiteral has a "type" property of "typed-literal".
However, section 3.2.2 specifies that this should be "literal".

- This same binding for "blurb" has used entity escaping in the text
of the value. While this is a valid XML fragment, I believe it was
intended for this fragment to encode an element. JSON does not require
entities to replace the < and > characters, and even if it were to be
used in literal JavaScript in a web page, the convention is to use a
CDATA wrapper on the script section to avoid problems with these
characters.


On a separate issue, I can't recall what has been discussed on this,
but will we be updating the XML Results Format document? The XML
version revers to URI exclusively (except for one reference in the
Internet Media Type Registration Form). This implies that only URIs
may be included in an XML response, meaning that some IRIs will be
invalid.

I presume that we want to keep the "uri" element in the XML schema,
for backward compatibility. I notice that the JSON Results Format
document refers to IRI everywhere, with the exception of the "type"
field for IRIs which is set to "uri", presumably for the same backward
compatibility.

Regards,
Paul Gearon
Received on Thursday, 1 September 2011 01:39:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT