Final fate of the json-ld short names?

iherman commented 5 years ago

This issue came up in https://github.com/w3c/pub-manifest/issues/29 with regard to referencing our spec. What do we plan for our final spec? Will it use the json-ld short name, ie, "hiding" the previous versions, or would we want a completely new "branch" and stick to json-ld11? It is important to make clear to other specs that want to refer to json-ld...

gkellogg commented 5 years ago

We registered short-names with "json-ld11" ("json-ld11", "json-ld11-api", "json-ld11-framing"). We also reference the previous spec, so "json-ld" should continue to point to the 1.0 spec.

akuckartz commented 5 years ago

As a user I expect "json-ld" to point to the most current spec.

iherman commented 5 years ago

We registered short-names with "json-ld11" ("json-ld11", "json-ld11-api", "json-ld11-framing"). We also reference the previous spec, so "json-ld" should continue to point to the 1.0 spec.

This is the situation today indeed. However, there may be some flexibility that we can discuss with the Webmaster (maybe in Fukuoka?). (See, e.g., https://www.w3.org/2005/05/tr-versions.html#shortnames.)

I propose we try to establish a scheme that we could live with, and then see what can be implemented.

iherman commented 5 years ago

A possibility may be:

/TR/json-ld -> points to the latest published recommendation
/TR/json-ld10 -> points to the highest level of 1.0
/TR/json-ld11 -> points to the highest level of 1.1

etc.

gkellogg commented 5 years ago

Does this have implications for the short-names used in the spec? Obviously, if /TR/json-ld can simply point to the same thing as /TR/json-ld11, I'm all in support of that.

References used internally are to JSON-LD11, JSON-LD11-API, and JSON-LD11-FRAMING. Would these change to the versions without "11"?

The JSON-LD reference is for 1.0, this could be changed to JSON-LD10, but may need either a custom bibliography, or some support in the document database. (Presumably, that's based on the cumulative specs in /TR, so something would need to be keyed from the content of the document).

iherman commented 5 years ago

@gkellogg frankly, I don't know exactly. I am happy to discuss this with the Webmaster, as soon as we agree what we want...

azaroth42 commented 5 years ago

:+1: to json-ld10 / json-ld11 / (etc) and json-ld as a pointer to the most recent.

iherman commented 5 years ago

Ok. I will contact our wise people in the W3C team to see what is possible for later.

iherman commented 5 years ago

This issue was discussed in a meeting.

ACTION: contact w3 team to determine possibility of json-ld shortname pointing to latest version (Ivan Herman)
View the transcript
Final short names
Rob Sanderson: See WG issue #103
Rob Sanderson: Ivan raised this issue. What should ‘jdonld’ point to in the future?
… 1.0 as it currently does, or the most recent version of the spec?
… There has been some discussion on the list.
… The suggestion is that ‘jsonld’ always points to the most recent,
… and ‘jsonld10’ and ‘jsonld11’ point to respective versions.
Ivan Herman: I have to check with the webmasters what exactly the rules are.
… If the WG is fine with this solution, I can start the discussion with them.
… Some people like pointin to the very last working draft,
… I’m not sure that’s a good idea, but we can discuss this later.
Gregg Kellogg: my concern is that this will change what ‘jsonld’ points to…
Ivan Herman: we need not solve this before CR
Rob Sanderson: are there other specifications who reference JSON-LD 1.0 via jsonld?
… this could lead to strange things for readers,
… especially if those spec say something like “JSON-LD does not support this”,
… while in fact JSON-LD 1.1 does.
Pierre-Antoine Champin: Just wanted to point out that JSON-LD pointing to something else is a matter of perspective. Currently it does point to the latest version
… I would argue it doesn’t change what we point to. Rob’s arguemtn about other specs is a good point.
Ivan Herman: to the best of my knowledge, no W3C spec referencing JSON-LD extend it in a way that azaroth suggests
… Groups out there may have done something nasty in that line,
… but well, they shouldn’t have been nasty.
Gregg Kellogg: if a spec has particular version dependency, they should point to a precise version
Benjamin Young: Activity Streams has its own media-type, because JSON-LD didn’t support lists of lists.
… What would be the impact on testing for other specs?
Rob Sanderson: +1 to dlongley
Ivan Herman: +1
Gregg Kellogg: +1
Benjamin Young: for the curious: https://www.specref.org/?q=json-ld
Dave Longley: I think that the benefit of having the latest version come up for ‘jsonld’ outweights the potential costs.
Action #1: contact w3 team to determine possibility of json-ld shortname pointing to latest version (Ivan Herman)
Gregg Kellogg: what does this mean for us? Sounds like “nothing” in the short term,
… except changing our references from ‘jsonld’ to ‘jsonld10’.
Ivan Herman: correct

iherman commented 5 years ago

(Got the answer from the Webmaster)

First of all, there is already a general setup to use common short names for versioned documents: see https://github.com/w3c/tr-pages/wiki/Latest-versions-proposal-for-leveled-specifications. Looking at that page, here is what we already have:

As a WG we can decide whether https://www.w3.org/TR/json-ld/ should point to:

https://www.w3.org/TR/json-ld/upcoming/ meaning it always points at the latest CR, PR, or Rec draft (this is a bit the HTML5 model of 'living standard'); or
https://www.w3.org/TR/json-ld/latest/ meaning it points at our latest recommendation

We can add this to our CR request. My feeling is that our preference would to to the latter, which means that once the REC is published, that one will appear as the top level.

azaroth42 commented 5 years ago

:+1: to latest, rather than upcoming

w3c / json-ld-wg

Final fate of the json-ld short names? #103