Issue 446 version announcement #473
Conversation
…ich was not the point of the test and causes errors in JSON parsers that are running in a strict mode.
…either using `processingMode` API option set to "json-ld-1.1", or `"@Version": 1.1` in the first encountered JSON Object context, otherwise processing mode set implicitly to "json-ld-1.0". Added checks with expected errors in context processing if new features used in context with the wrong processing mode. Also adds compact/expand tests to check for proper error reporting. Fixes #446.
| @@ -0,0 +1,5 @@ | |||
| { | |||
| "@context": { | |||
| "@version": 1.1 | |||
There was a problem hiding this comment.
Do we want this to be a number (float/double) or a string? Expressing version attributes as strings seems to be fairly common practice.
There was a problem hiding this comment.
@lanthaler suggested a number, as using a string would be silently ignored by most 1.0 processors; the point is to use something that would cause a 1.0 processor to halt, thus the number.
There was a problem hiding this comment.
Ah, right, I forgot about that. Bummer.
| The processing mode defines how a JSON-LD document is processed. | ||
| By default, all documents are assumed to be conformat with | ||
| <a data-cite="JSON-LD-20140116">JSON-LD 1.0</a> [[!JSON-LD-20140116]]. By defining | ||
| a different version using the <code>@version</code> member in a |
There was a problem hiding this comment.
I suppose there may be good reasons for decoupling the version from the processing mode, but figured I'd throw out the idea that we could do @processingMode instead of @version as a means by which to set the preferred processing mode via the @context -- rather than inferring it from @version.
There was a problem hiding this comment.
That thought occurred to me, but it would be more natural, then, to say "@processingMode": "json-ld-1.1", which would pass a 1.0 processor silently.
An alternative suggested by @lanthaler was to use something like "@processingMode": ["json-ld-1.1"], which would error by a 1.0 processor, would would allow the symmetry with the API mode. Personally, I preferred using the simpler numeric value, but I could be convinced to go the other way.
There was a problem hiding this comment.
I don't feel that strongly, so I'm ok with going forward with the numeric proposal for now given its necessity for causing a 1.0 processor to halt.
There was a problem hiding this comment.
LGTM -- I only did a quick pass over as I'm time limited. We may want to be a little more clear that the version value is a JSON Number. I think this is the best path forward we've come up with so far so I'm +1 to merge. We can make further changes as needed after more feedback comes in.
|
Thanks @dlongley: I'll add some additional text to clarify that the value is the JSON number |
Adds announcement requirement and tests as required in #446.