W3C home > Mailing lists > Public > public-linked-json@w3.org > August 2018

Re: Why is the value of @version a number?

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Sat, 18 Aug 2018 09:52:58 -0700
Message-Id: <497D5B66-33B2-4295-9911-FAFD67E5E83A@greggkellogg.net>
Cc: Robert Sanderson <azaroth42@gmail.com>, Lutz Helm <helm@ub.uni-leipzig.de>, Linked JSON <public-linked-json@w3.org>
To: Asbjørn Ulsberg <asbjorn@ulsberg.no>
> \On Aug 18, 2018, at 4:59 AM, Asbjørn Ulsberg <asbjorn@ulsberg.no> wrote:
> 
> 
> Do I understand the versioning correctly in that it is not a semantic version number?
> 
> https://semver.org/ <https://semver.org/>
> 
> If JSON-LD followed SemVer, 1.0 processors should be able to process all 1.x versions of JSON-LD, but not 2.x, since the major version indicates breaking changes.
> 
> If there’s breaking changes in 1.1, it can surprise implementors since according to SemVer that’s supposed to be backwards compatible with 1.0.

(Not an official response, but my perspective on the choice of versioning).

Perhaps a difference of interpretation, but 1.1 is fully backwards compatible with 1.0. There is new functionality introduced, which requires the @verision signaling. According to the sited semver:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Changes are backwards compatible and new functionality is added (the “within the private code” part is problematic). In my experience, new minor versions of software using semver often introduce new functionality, that you can’t expect software conforming to a previous version to implement. For this, there is patch versioning. Major versions are for when previously compliant code would break with the new version, which is not the case here.

That said, the choice of versioning at W3C can be IMHO more political than technical, and it’s not likely we’ll see a 2.0 version in spite of any changes that may be made. For this, we need look at the charter [1]: “All changes must preserve backward compatibility for JSON-LD 1.0 documents.” But, this may be subject to interpretation by the WG.

Gregg

[1] https://www.w3.org/2018/03/jsonld-wg-charter.html <https://www.w3.org/2018/03/jsonld-wg-charter.html>

> --
> Asbjørn Ulsberg    -=|=-    asbjorn@ulsberg.no <mailto:asbjorn@ulsberg.no>
> «He's a loathsome offensive brute, yet I can't look away»
> 
> On lør., aug. 18, 2018 at 0:18, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> I understand the concern, but at the speed of W3C standards, the likelihood of ever getting above 1.9 is extremely extremely low :D
> 1.0 started in 2012, 1.1 started 2018 ... extrapolating, it would be 2072 before we would need a 1.10
> 
> W3C does not have patch version, only external errata. I think a floating point number is fine here.
> 
> Rob
> 
> On Fri, Aug 17, 2018 at 3:01 PM, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
> > On Aug 17, 2018, at 6:52 AM, Lutz Helm <helm@ub.uni-leipzig.de <mailto:helm@ub.uni-leipzig.de>> wrote:
> > 
> > Hi,
> > 
> > I just stumbled upon the fact that @version has to be a number in json-ld 1.1 contexts. Is there any reason why this is not a string?
> > I guess it shouldn't ever happen that a spec is released as patch version, and there will probably not be more than eight more versions with nonbreaking changes to the spec, so a decimal number might suffice, but I'm still a little bit puzzled.
> 
> The reason @verion is a number, specifically 1.1, is so that a 1.0 processor not prepared for it will through an error, as every other value must either be a string, null, or an object. We want a 1.0 processor to stop processing so that it does not interpret the context and associated JSON-LD in a way which is different than a 1.1 processor would, so we make sure it will raise an exception.
> 
> Gregg
> 
> > Best regards,
> > Lutz
> > 
> > -- 
> > Lutz Helm
> > Bereich Digitale Dienste
> > AG Anwendungsentwicklung
> > 
> > Universitätsbibliothek Leipzig
> > Beethovenstraße 6, 04107 Leipzig
> > 
> > T: +49 341 97 30566
> > 
> > helm@ub.uni-leipzig.de <mailto:helm@ub.uni-leipzig.de>
> > https://www.ub.uni-leipzig.de/ <https://www.ub.uni-leipzig.de/>
> > 
> > 
> 
> 
> 
> 
> 
> -- 
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049


Received on Saturday, 18 August 2018 16:53:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:52 UTC