Backward compatibility in the charter

[iherman]

Backward compatibility in the charter

[gkellogg]

There are some areas where a 1.1 processor, operating in 1.0 mode, will compact differently. Notably, compact IRI generation was seriously broken, and it's been "fixed" (see json-ld/json-ld.org#405).

Note that expanding and turning JSON-LD into N-Quads is not affected, only compaction for a feature that was arguably broken. (e.g., define sport as schema:sport and compact http://schema.org/sportsEvent, yielded sport:sEvent, when what was desired is schema:sportsEvent).

There is currently an issue on compacting literals without language using a language map (using the @none index), but this will likely resolve to require 1.1 mode to operate this way.

We can say that a 1.1 processor will "process" (as in expand) a 1.0 document the same as a 1.0 processor, but not, strictly speaking, that all transformations will generate exactly the same results.

[iherman]

@gkellogg, I saw the changes, but I think it is way too detailed for a charter. Can we say something like

When processing legacy JSON-LD documents, JSON-LD processors generate the same expanded output (the only exception is related to an erratum in JSON-LD 1.0 (put reference here)).

Do we have to say anything in the charter about the compact case? I am not sure. The expanded form is the closest to an RDF equivalence, and that is it.

(AC members who will vote on the charter will not really know what we are talking about with the text that is currently in the latest commit...)

[gkellogg]

but I think it is way too detailed for a charter

I just copied information from the Changes section, but sure, I'll change it.

[gkellogg]

The expansion case is related to json-ld/json-ld.org#470, which hasn't been, but should be filed as an erratum. I'll update the text to point to the errata, but we need to get that filed somehow. Would that simply start as an email to [email protected]?

To be complete, we should also file json-ld/json-ld.org#405.

[iherman]

Yes, we should follow the official errata procedure, which entails that email indeed...