communicaton about Turtle compatibility

What's our story on versioning (backward and forward compatibility) for
the Turtle language?

I think it's:

1. There are various "pre-standard" turtle parsers out there; they're
going to have to be changed to handle new "standard" turtle, which has
some new bits.

2. There are various "pre-standard" turtle documents out there; they'll
be handled by some "pre-standard" parsers and all standard parsers
(unless they're really, really strange).

3. If someone (including W3C RDF WG) wants to add extensions to Turtle,
or somehow make a different version, they have to call it something
different and give it a different media-type (not text/turtle) and
suffix (not .ttl).

In other words, there will only ever be one "true" version of Turtle.
There will never be a Turtle 1.1, and if there is ever a "Turtle 2" it
will formally be a different language, with different documents,
different parsers, and different media types.   If Turtle 2 is an
extension of Turtle, then Turtle 2 parsers can claim the Turtle mime
type as well and also handle Turtle (.ttl) documents.

This is sensible, I think, and I can't think of a better plan.  I don't
think it's worthwhile to somehow put a version flag in the document
text, or to have some kind of "ignore stuff you don't understand" rule
like HTML and CSS.   So I'm not suggesting changing anything in the
language.

It might be helpful to say something in the introduction or SOTD about
how we've tried to be backward compatible with existing pre-standard
Turtle documents.   (We don't need to say there is no forward
compatibility, since that would just confuse nearly everyone.)  I think
this is something people are going to want to know.  It might just be
something we say in the various news announcements, but I wouldn't mind
seeing it acknowledge even in the Abstract.

   -- Sandro

Received on Saturday, 12 May 2012 19:52:51 UTC