Re: Comment on SPARQL 1.1 CSV Results

Rob,

After discussion, particularly around the ability to reuse existing CSV 
parsers and writers, the working group feels that your option 1 is the 
better tradeoff.  Specialised encoding rules would be lost when using 
existing general parsers.  Other formats, such as the TSV format, do 
provide the ability to distinguish empty string from unbound.

	Andy

[1]
http://www.w3.org/2009/sparql/docs/csv-tsv-results/results-csv-tsv.html#csv-terms

On 05/02/12 19:51, Andy Seaborne wrote:
> Rob,
>
> Thank you for catching that. I've added text to the editor's working
> draft, noting the fact and requiring the quoted empty string be used
> (your option 2). This text will be considered by the working group when
> it next reviews the document for publication.
>
> I would be grateful if you would acknowledge that your comment has been
> answered by sending a reply to this mailing list.
>
> Andy
>
> On 03/02/12 23:17, Robert Vesse wrote:
>> Hi All
>>
>> There is a problem with this document in that it does not state how and
>> if the serialization should handle empty strings.
>>
>> The spec states that terms are serialized as if the STR() function had
>> been applied and that there should be no distinguishing syntax for term
>> type, thus the serialization should only surround a literal in quotes
>> when that literal contains characters that cannot be serialized bare
>> in CSV.
>>
>> Also the spec states that an unbound term is serialized as an empty field
>>
>> What this means is that the spec requires you to serialize an empty
>> string in the same way you serialize an unbound term. Thus if you were
>> to parse the serialization you would have to assume that it was an
>> unbound term.
>>
>> I am aware that the CSV serialization is intentionally lossy by design
>> so I'd like to suggest that the working group do one of the following:
>>
>> 1 - Have the document state that this case (empty string vs unbound
>> term) is a known ambiguity in the serialization
>> 2 - Require an empty string to be serialized as ""
>>
>> Option 2 would be my preference
>>
>> Regards,
>>
>> Rob Vesse
>>>
>>
>

Received on Monday, 13 February 2012 11:46:35 UTC