[VOTE] Mark JSON-LD 1.0 as superseded

[BigBlueHat]

The Chairs and Editors propose that the JSON-LD 1.0 specification should be marked as superseded by the JSON-LD 1.1 specification released July 11, 2020.

The 1.1 specifications provide 1.0 compatibility. Additionally, processors can use the json-ld-1.0 processing mode to explicitly ignore 1.1 features seen in data documents and contexts:

The API provides an option for setting the processing mode to json-ld-1.0, which will prevent JSON-LD 1.1 features from being activated, or error if @version entry in a context is explicitly set to 1.1. This specification extends JSON-LD 1.0 via the json-ld-1.1 processing mode.

We believe this is sufficient to mark the 1.0 specification as superseded.

Please provide your vote as a comment on this issue.

Thanks!

[gkellogg]

👍

[davidlehn]

+1

[dlongley]

+1

[rubensworks]

👍

[pchampin]

+1

On 27/08/2020 16:23, BigBlueHat wrote:

The Chairs and Editors propose that the JSON-LD 1.0 specification https://www.w3.org/TR/json-ld1/ should be marked as superseded by the JSON-LD 1.1 https://www.w3.org/TR/json-ld/ specification released July 11, 2020.

The 1.1 specifications provide 1.0 compatibility. Additionally, processors can use the |json-ld-1.0| processing mode https://www.w3.org/TR/json-ld/#dfn-processing-mode to explicitly ignore 1.1 features seen in data documents and contexts:

The API provides an option for setting the processing mode to
|json-ld-1.0|, which will prevent JSON-LD 1.1 features from being
activated, or error if |@version| entry in a context is explicitly
set to 1.1. This specification extends JSON-LD 1.0 via the
json-ld-1.1 processing mode.

We believe this is sufficient to mark the 1.0 specification as superseded.

Please provide your vote as a comment on this issue.

Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/json-ld-wg/issues/154, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACKLZBOD5UMHA6QVT77BKTSCZT6PANCNFSM4QNBUKNA.

[BigBlueHat]

👍

[iherman]

I think we can call this. I will start the relevant administration.

[TallTed]

@iherman @gkellogg -- JSON-LD 1.0 is indeed now marked as superseded, but it lacks the big red "this is old, go to the new" that have been added to more recently superseded docs, and which help a LOT in preventing people from discovering the new doc late in their process, having wasted time conforming to the old doc.

[gkellogg]

Maybe this is something that still needs attention from @pchampin? Reopening.

[pchampin]

"superceded" and the "outdated" red popup play slightly different roles.

• The red popup appears whenever a more recent version of the same specification exists. In particular, it appears when you click on the "Previous version" link in any spec.
• Superceded is a relationship between two distincts specifications belonging to the same series.

In the case of JSON-LD Syntax (the same applies to JSON-LD API), we have two specifications, namely JSON-LD 1.0 (see its history) and JSON-LD 1.1 (see its history). In each case, the red popup appears if you click on any version but the last one. Both belong to the json-ld series, and so the short URL TR/json-ld points to the latest version of the latest specification of the series.

Other examples are dcat-vocab-2 superceding dcat-vocab-1, or rdf11-concepts superceding rdf10-concepts (although the latter does not use the "superceded" terminology for historical reasons). Note that the superceded versions do not display the red popup either. There might be counter examples elsewhere (this things have evolved organically, and our systeam manages a lot of special cases), but I believe the JSON-LD is the expected behaviour.

[TallTed]

[@pchampin] I believe the JSON-LD is the expected behaviour

It is not my expected behavior, especially given that when you go to JSON-LD 1.0, it has a Latest published version of http://www.w3.org/TR/json-ld/ — which is (today) JSON-LD 1.1, and will (soon-ish) be JSON-LD 1.2!

Also note that JSON-LD 1.0's Previous version is http://www.w3.org/TR/2013/PR-json-ld-20131105/, which has the big red popup, which says, "For the latest version, please look at https://www.w3.org/TR/json-ld/" -- which, again, is JSON-LD 1.1!

Bottom line, if "the JSON-LD is the expected behaviour", I strongly believe those expectations (and that behavior) should be changed.

[pchampin]

[@pchampin] I believe the JSON-LD is the expected behaviour

It is not my expected behavior, especially given that when you go to JSON-LD 1.0, it has a Latest published version of http://www.w3.org/TR/json-ld/ — which is (today) JSON-LD 1.1, and will (soon-ish) be JSON-LD 1.2!

Also note that JSON-LD 1.0's Previous version is http://www.w3.org/TR/2013/PR-json-ld-20131105/, which has the big red popup, which says, "For the latest version, please look at https://www.w3.org/TR/json-ld/" -- which, again, is JSON-LD 1.1!

You are right, this is confusing, and should be fixed. But I will argue that this does not contradict what I wrote above. Here is why:

• The short name of JSON-LD is (again for historical reasons), json-ld. So the short URL for this specification started as https://www.w3.org/TR/json-ld/.
• When JSON-LD 1.1 was started, a series was created, whose short name is json-ld, repurposing the above URL to be the tip of the series rather than the tip of the JSON-LD 1.0 specification. Anyway, both were identical until then, so this is cool).
• At the same time, an alias json-ld1 was created to provide short URLs for the JSON-LD 1.0 specification.

So in the two cases you cite above, https://www.w3.org/TR/json-ld/ should be replaced with https://www.w3.org/TR/json-ld1/, in order to be consistent with the rest.

Bottom line, if "the JSON-LD is the expected behaviour", I strongly believe those expectations (and that behavior) should be changed.

I disagree that it should be changed, but I grant you that 1) we must carefully fix all the inconsistencies that make it confusing, and 2) we should probably add an entry in the superceded recommendation's header, counterpart of the "Previous recommendation" entry in the superceding recommendation's header.

[TallTed]

1. we must carefully fix all the inconsistencies that make it confusing, and 2) we should probably add an entry in the superceded recommendation's header, counterpart of the "Previous recommendation" entry in the superceding recommendation's header.

+1