Conversation
explain how to deal with multiple version directives, and with the absence of version directive recall that the version information is just a hint, and suggest to avoid version directives with version "1.1" see also w3c/rdf-n-triples#90 which should eventually be reflected in this document, and complement this PR
|
|
||
| <p> | ||
| In the absence of a version announcement directive, the version specified as part of the <a href="#sec-mediaReg">Media Type</a> is considered, if any. | ||
| In the absence of any version information, a sensible default is `"1.1"`, to maximize compatibility with the previous version of Turtle [[TURTLE]]. |
There was a problem hiding this comment.
If this is done by a parser, it might lead the parser to fail on triple terms. And similarly if this is done by a serializer. This default seems pointing implementation to effectively require VERSION 1.2 to be there if 1.2 features are used.
There was a problem hiding this comment.
This default seems pointing implementation to effectively require VERSION 1.2 to be there if 1.2 features are used.
No, not "require". The next sentence says:
"In any case, the version announcement is merely a hint; parsers are not required to reject features that are outside the announced version (but could signal them with a warning)."
So yes, the encouraged practice would be:
- old Turtle file or 1.1-compatible file contain no VERSION directive
- files with Triple-terms contain VERSION "1.2", so that old parser can err early, with an explicit message
but lenient parsers can still accept triple terms if no VERSION directive is given.
There was a problem hiding this comment.
Thank you!
So yes, the encouraged practice would be:
Agreed to the practice for serializers. However, I do not see how it relates to my comment that was aimed at parsers. In this case, just pushing them to do even things like "signaling as a warning" in case of absence of version information looks quite cumbersome to me in real life. I would tend to encourage as broad compatibility as possible.
There was a problem hiding this comment.
In this case, just pushing them to do even things like "signaling as a warning" in case of absence of version information looks quite cumbersome to me in real life. I would tend to encourage as broad compatibility as possible.
+1 to encourage broad compatibility; that is why I would discourage parsers to raise errors when the content of a file does not match the announced version.
But I disagree that raising a warning (when RDF 1.2 features are encountered without proper version announcement) is hindering compatibility. It is a only warning after all...
That being said, I grant you that the warning may not reach the right target anyway... If the server does not follow good practices and sends triple terms without any version announcement, it is the client who will get a warning when parsing that...
The PR has been merged, but feel free to make a counter-proposal as a new PR if you think a better wording is required.
Co-authored-by: Andy Seaborne <andy@apache.org> Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
5 participants
fix #118
Preview | Diff