On Fri, 2011-06-03 at 10:36 +0100, Andy Seaborne wrote:
>
> 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.
> """
*shrug* I'm not seeing that as an improvement.
> (double comma in the draft text sentence BTW).
Thanks. I had to stare at that for a long, long time before I was able
to see it.
> >
> >>> 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.
Good point; I've rephrased that sentence which covers Turtle to be more
broad:
"""
The group may make minor changes to SPARQL in order to align with
changes and clarification of RDF and Turtle coming from the RDF Working
Group, being careful not to require burdensome changes for existing
SPARQL deployments.
"""
-- Sandro