W3C home > Mailing lists > Public > public-json-ld-wg@w3.org > April 2021

Re: JSON-LD 1.0 - "superseded" UI on site is overly harsh and pushy

From: Benjamin Young <byoung@bigbluehat.com>
Date: Mon, 26 Apr 2021 18:50:16 +0000
To: Dan Brickley <danbri@google.com>, Gregg Kellogg <gregg@greggkellogg.com>, Ivan Herman <ivan@w3.org>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org>, Ralph Swick <swick@w3.org>
Message-ID: <BN7PR06MB40492D6506BF008C9BEAC80CB2429@BN7PR06MB4049.namprd06.prod.outlook.com>
Thank you for raising this, Dan! I've complained (sorry I haven't done more...) about this for years... It's the same issue on old notes like this one: https://www.w3.org/TR/web-packaging/

The spec may be "superseded," but that doesn't mean it's unread and making the reading experience painful just makes the W3C expxerience painful...which none of us want...

Could we address the "UX concern" first (Ralph, perhaps?), and then revisit the more JSON-LD spec history/processing related languages second?





From: Dan Brickley <danbri@google.com>
Sent: Monday, April 26, 2021 2:40 PM
To: Gregg Kellogg <gregg@greggkellogg.com>; Ivan Herman <ivan@w3.org>; W3C JSON-LD Working Group <public-json-ld-wg@w3.org>; Ralph Swick <swick@w3.org>; Benjamin Young <byoung@bigbluehat.com>
Subject: JSON-LD 1.0 - "superseded" UI on site is overly harsh and pushy

Hi folks,

There is a problem with the citability of the JSON-LD 1.0 specs as currently published at W3C.

In Google's original objection to the JSON-LD 1.1 charter (which I largely wrote), we went to verbose pains to urge W3C not to undermine what it had achieved with JSON-LD 1.0's adoption. I feel like that's happened anyway. https://lists.w3.org/Archives/Public/public-new-work/2018May/0000.html

I have just gone to W3C to look something up to send to a colleague - https://www.w3.org/TR/2014/REC-json-ld-20140116/#identifying-blank-nodes - and this (screenshot below) is the user experience - it basically tells people to use 1.1 instead. As you know 1.1 contains a bunch of new stuff, and the strong push towards the 1.1 spec with the warning loses the specificity of what is being pointed to. While I can understand the desire to draw attention to the existence of related later specs, many readers are going to be there to understand implementation constraints being documented by others, so pointing at a literally different spec is not helping them, W3C, or the implementor.

Context - this from Ivan, https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Nov/0000.html -

> FYI: the old, 1.0 versions of JSON-LD 1.0 and JSON-LD API 1.0 are now officially superseded. (This should have been done when we published the 1.1 version, but it fell between the cracks :-(

Currently - apart from the context-discovery mechanism using HTTP headers, Schema.org's very substantive deployment across the web is based on JSON-LD 1.0, and getting to that stage was not easy. We need to simply and clearly be able to cite the JSON-LD 1.0 specs without confusing implementers (data consumers) and publishers by making it look like the approach is obsolete. Right now, visitors to the those documents get upsold to go learn about a different, later technology instead.

It would be misleading to publishers and to data consumers at this moment to say that Schema.org uses or endorses JSON-LD 1.1, although of course the project wishes the 1.1 endeavour every success. I haven't dug out the specific assurances made around the launch of the 1.1 WG but I thought the spirit of our understanding was a mutual "let's not undermine the success we've only just achieved with 1.0". For example, it isn't even clear in 2021 which search engines understand JSON-LD 1.0 (or some subset) for Schema.org use (as opposed to say Microdata in HTML5). I don't believe the new additions in https://www.w3.org/TR/json-ld/#changes-from-10 has got much attention yet, for the public web markup usecases focussed on at Schema.org. I thought 1.1 was understood to be targeted at those usecases for which new expressivity in JSON-LD's context mechanism was really useful, and that those of us who were happy enough with 1.0 would be left in peace to continue using it.

I appreciate that the "processing mode" machinery allows for situations in which solely 1.0 content can be reliably discovered and correctly interpreted, ... but by making the 1.0 specs almost impossible to be sensibly linked to, it becomes very hard to say "write your documents per the 1.0 specs", and point to the stable W3C specs we're supposedly relying on. When someone cites a 1.0 spec, having the spec urge the reader to learn about 1.1 instead is both counter-productive and confusing. What's the point of having a standard that can't be cited?

The world has larger problems right now, but this does feel to me like undermining one of the bigger success stories in terms of a widely deployed W3C RDF format.

According to https://www.w3.org/2020/Process-20200915/#rec-rescind

" Abandoning a W3C Recommendation"

... JSON-LD 1.0 is abandoned.

Should I feel like a schmuck for talking 10s of millions of sites into using it, or happy because they're also in some tenuous sense equally users of JSON-LD 1.1 too? Should we really be pointing webmasters and publishers at the 1.1 spec when there was never any expectation it would target Schema.org's usecases?

My main concern here is with the ability to document Schema.org by saying "For use in search engines, Schema.org can be written in JSON-LD 1.0" and having something reliable to point to. Maybe sometime it'll be possible to say that about 1.1 too. Should we be looking at requesting the superseded status to be restored, or could the popup warning shown on rescinded specifications be made less pushy and upselly?

Thanks for any thoughts,


Attached screenshot:

ALT description: it shows JSON-1.0 spec, greyed out with a big red warning saying "This version is outdated! For the latest version, please look at https://www.w3.org/TR/json-jd/" (UI has a collapse button which seems to hide the warning).

[Screen Shot 2021-04-26 at 6.26.42 PM.png]

Screen Shot 2021-04-26 at 6.26.42 PM.png
(image/png attachment: Screen_Shot_2021-04-26_at_6.26.42_PM.png)

Received on Monday, 26 April 2021 18:50:40 UTC

This archive was generated by hypermail 2.4.0 : Monday, 26 April 2021 18:50:42 UTC