Re: pls review CSV changes (was Re: while we are rechartering.... (csv))

On 03/06/11 06:06, Sandro Hawke wrote:
> On Thu, 2011-06-02 at 13:55 +0100, Andy Seaborne wrote:
>>
>> On 01/06/11 17:42, Sandro Hawke wrote:
>>> On Wed, 2011-06-01 at 17:31 +0100, Andy Seaborne wrote:
>>>> I'm OK with this except I don't think it's a "new information" matter
>>>> but a "decide later" matter.
>>
>>> Can you be a little more specific - I don't follow.
>>
>> "new information" is a bit unclear when the key fact is internal
>> resourcing.  "New information" is usually more about external factors -
>> not always but typically.  So delay the decision for now, not make
>> it/maybe remake it.
>>
>>> What I was suggesting we that we'd resolve: "We'll produce a spec for
>>> sparql results in CSV and/or TSV.   Given our current timeline and
>>> staffing, it will be a WG Note."
>>
>> As per your original suggestion:
>>
>> """
>> making this a time-permitting
>> feature, optionally on the Rec Track?
>> """
>>
>> I'd prefer to leave open the possibility of a REC in the rechartering.
>
> I've edited the draft charter again.  Look for the strong "csv", which
> now occurs in four places in the document.

Look good.

I'm also OK if you want to say a slightly more pro-NOTE form like:

"""
SPARQL 1.1 Query Results CSV/TSV Format, time permitting; may be either 
Working Group Note, or a Recommendation if sufficient time permits, as 
decided by the the Working Group. These would put query results directly 
in the popular "Comma-Separated-Values" (RFC 4180) and/or 
Tab-Separated-Values formats.
"""

(double comma in the draft text sentence BTW).

>
>>> Then, if the timeline or staffing change significantly, we would
>>> reconsider Note-vs-Rec.
>>
>> Stepping back:
>>
>> The wave function in RDF-WG about strings seems to be collapsing to
>> something that I can believe will be stable.
>>
>> As this is something that is directly visible to applications, through
>> SPARQL or otherwise, the potential to revise the SPARQL docs late in the
>> process would be good even if we slip a few months.  There's a window of
>> opportunity to get specs lined up for once (and from experiences
>> chashing through RFCs on, say host name formats, it's quite a valuable
>> thing to have).
>
> Does this have implications on the charter?   If so, I'm not seeing that
> part.

Timescale mainly, adding a few months of padding at the end, after 
proposed REC date, if nothing chnages, for "sorting out"

Also the "Compatibility Expectation" would it be a good idea to add 
something about xsd:strings? (no opinion - just asking).

The text:
"""
The group may make minor changes to increase alignment with Turtle 
standardization by RDF Working Group, being careful not to require 
burdensome changes for existing SPARQL deployments.
"""
cover Turtle.  I expect that simpleliteral/xsd:string will be part 
Turtle and part the natural consequences.

DATATYPE("foo"@en) => rdf:LangTagString

The fact that BGP matching changes is not a SPARQL issue per-se as 
SPARQL defers to RDF.

The fact that XML results might get reopened to add a sentrence about 
using plain literals is already in-scope.

>
>      -- Sandro
>
>

 Andy

Received on Friday, 3 June 2011 09:37:21 UTC