[RESOLVED] Re: Turtle implementation report for RDF::Trine

On Sep 3, 2013, at 10:55 AM, Sandro Hawke <sandro@w3.org> wrote:

>> I see at [1] that this comment has been marked as resolved, despite my quoted response above indicating that I didn't believe the second part of my comment had been addressed at all. Can this please be fixed, or another comment line be created for this issue?
>> 
>> thanks,
>> .greg
>> 
>> 
>> [1] http://www.w3.org/2011/rdf-wg/wiki/Turtle_Candidate_Recommendation_Comments#c18
>> 
> 
> Greg, my apologies on behalf of Eric and the Working Group for incorrectly marking this as resolved, and for not responding earlier about the DOT rules.   I agree those rules look odd/confusing, but hopefully when I explain our reasoning it will make sense.
> 
> The reasoning is this: we expect Turtle to be written in one of two styles: old-style and new-style.     (We have another open comment about what to call them - perhaps Turtle 1.0 and Turtle 1.1 - but I'll call them "old" and "new" for now.)
> 
> Old-style is what works in non-updated parsers.    We suggest systems keep generating output in this style for a little while longer, until nearly all deployed software has been updated to handle the upcoming Turtle REC.   People can watch the Implementation Report to judge when this is.   For old-style Turtle, we don't want to make the DOT optional because if one left out the DOT, the file wouldn't be parsed by old parsers, defeating the purpose of using old-style Turtle.   (Meanwhile, while we expect the *parsers* to migrate to new-style turtle, we understand there will be old-style *files* floating around for the foreseeable future. That's why we made the new-style an extension of the old style, so all new parsers can always handle old files they come across.)
> 
> New-style is Turtle with the various extensions we've added, including SPARQL-style PREFIX and BASE.   The idea here is to allow users to cut-and-paste their PREFIX lines (which are often long and inscrutable) between Turtle and SPARQL, and perhaps train their fingers to write it that particular way.   Here, if we made DOT optional, someone who used the DOT in Turtle would find SPARQL systems rejecting their PREFIX declaration, since SPARQL doesn't require allowing the DOT.
> 
> Of course, Turtle and SPARQL systems are free to extend the language by allowing a DOT after PREFIX and BASE, but unless there is coordination among extensions like this, we believe it will confuse users and reduce interoperability, because some users will think it's allowed since it works in their system.
> 
> Does that make sense?    We can make new Turtle parsers handle any variant, but in practice we expect to have only two: the one that's compatible with old turtle parsers and the one that's compatible with SPARQL parsers.    Hopefully old turtle parsers will die out soon, and we'll be left with just one style.    If we make the DOT rules more flexible, we end up making the compatibility situation actually more complex.
> 
> Please reply and let us know if this response addresses your concern.   If not, would you mind starting a new thread (not "replying" to this email), and we'll track it as an issue about DOT instead of PREFIX and BASE?
> 
> Thanks again for your patience and help ironing out these details.

Sandro,

Sorry for the great delay in responding. I continue to disagree with this reasoning, but understand it and appreciate the working group’s consideration on this topic. Therefore, I’m willing to consider the issue resolved.

thanks,
.greg

Received on Wednesday, 6 November 2013 00:57:31 UTC