Re: Comment on SPARQL 1.1 CSV Results

Perhaps something like:

"""
Note that the standard CSV format does not distinguish between missing 
values and empty strings. Because of this, the SPARQL 1.1 CSV Results 
Format uses the same representation for unbound variables as for 
variables bound to an empty string literal. Clients that require the 
ability to distinguish between these two cases should use the TSV, XML, 
or JSON results format instead of the CSV format.
"""

Lee

On 2/6/2012 4:08 AM, Andy Seaborne wrote:
> Greg, Lee,
>
> I presume you agree with option 1 then.
>
> What wording do you suggest in section 3.2 or elsewhere?
>
> Andy
>
> On 06/02/12 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.
>>
>> .greg
>>
>>
>
>

Received on Monday, 6 February 2012 14:22:22 UTC