W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2012

Re: Comment on SPARQL 1.1 CSV Results

From: Steve Harris <steve.harris@garlik.com>
Date: Mon, 6 Feb 2012 12:45:17 +0000
Cc: "Eric Prud'hommeaux" <eric@w3.org>, Lee Feigenbaum <lee@thefigtrees.net>, Andy Seaborne <andy.seaborne@epimorphics.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <578525D0-4677-45AA-9587-667D9120ED88@garlik.com>
To: Gregory Williams <greg@evilfunhouse.com>
On 6 Feb 2012, at 01:52, Gregory Williams wrote:

> On Feb 5, 2012, at 7:46 PM, Eric Prud'hommeaux wrote:
>> On Sun, Feb 5, 2012 at 18:57, Lee Feigenbaum <lee@thefigtrees.net> wrote:
>>> I agree with Greg.
>>> Given that the CSV format is purposefully simple and lossy, I think that
>>> unbound variables and empty strings should both be empty strings in CSV,
>>> which can be either ,, or ,"",
>> I believe the use of existing libraries argument is more salient for
>> parsers than for serializers (i.e. printf loops). What then is the
>> harm in specifying the "" distinction, which only some parsers will
>> distinguish?
> While CSV is a trivial format, I'd suggest that it's not just a matter of "printf loops". There still is escaping to be done, and leaving it to a library is always safer than trying to hack it together in a loop.


> Also, I'm worried about us trying to define semantics based on syntactic variations that are specified as being equivalent. It's no longer 'just CSV' if we're ascribing semantics to whether you use ,, or ,"",. The CSV format is inherently lossy, so I'm not sure why this particular case should be any more of an issue than others.


I prefer option 1.

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, Nottinghamshire, England NG80 1ZZ
Received on Monday, 6 February 2012 12:51:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:10 UTC