changed definition of the rdf:JSON datatype

[pchampin]

addressing #323

Note that the description of the canonical form, which used to be non-normative (and using SHOULD) is now normative and uses MUST. It seemed inappropriate to define the value space non-normatively... :-/

As a consequence, the corresponding text in API 8.6 Data Round Tripping is states:

The canonical lexical form of a JSON literal value is non-normative,

and still uses SHOULD. I guess we should update it as well?

---

Preview | Diff

[iherman]

As a consequence, the corresponding text in API 8.6 Data Round Tripping is states:

The canonical lexical form of a JSON literal value is non-normative,

and still uses SHOULD. I guess we should update it as well?

Yes. But I would simplify the whole portion of the text related to the JSON literal: let us not repeat the canonicalization algorithm (although we do not use the term 'canonicalization' in the new version of the syntax:-), but just refer to the value space of the JSON Literal, as defined in the syntax document. The value space being valid JSON, that should be somehow enough for the round tripping: a value in the value space is also a valid lexical form for the JSON part.

(Yes, this means that there is no roundripping for JSON literals in the sense of keeping the original key order, spaces, indentation, etc. Let it be...)

[iherman]

(I wonder why github replicated my comment three times...)

[pchampin]

@iherman

I believe that the lexical-to-value mapping section must be changed as well.

It was changed... and it does reference the constraints described in the definition of the value space.

(I wonder why github replicated my comment three times...)

It didn't, at least from where I stand.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Update api document to be in line with syntax for json datatype, test descriptions, and “canonicalization” algorithm (modulo key ordering)
  View the transcript

  Boolean comparison issue (JSON Datatype)
  link: https://github.com/w3c/json-ld-syntax/issues/323))
  Rob Sanderson: Last week, we concluded that we should fix 323.
  Pierre-Antoine Champin: The value of the JSON value type should not be a structured representation of JS object, but canonical form of JSON representation.
  … We have our own canonic process. But this was marked as non-normative. I think this should be marked as normative.
  Ivan Herman: Yes, I agree.
  … You avoided canonicalization term, which is a good idea.
  pr: https://github.com/w3c/json-ld-syntax/pull/325
  … There is a small part that needs to be changed.
  Pierre-Antoine Champin: I did change it.
  Ivan Herman: I may have missed something then.
  Pierre-Antoine Champin: Currently lexical value should be re-serialized.
  Gregg Kellogg: Reason it was non-normative was JSC was still in draft.
  … Object keys are ordered by converting them by UTF16 may be controversial.
  Pierre-Antoine Champin: We should update the API doc as a copy of the normalization text in processing document.
  Gregg Kellogg: We should also change the test descriptions.
  Ivan Herman: Also the API doc currently repeats the canonicalization steps, and we should refer to the proper place.
  … We will get a similar situation as with language tags, where we can not fully guarantee roundtripping.
  Gregg Kellogg: Yes. Ordering of keys in our case is just lexicographical, while JSC is much more detailed with localization concerns.
  Proposed resolution: Update api document to be in line with syntax for json datatype, test descriptions, and “canonicalization” algorithm (Rob Sanderson)
  Gregg Kellogg: Not including that in syntax doc would not be sufficient for interoperation.
  Gregg Kellogg: +1 (modulo key ordering)
  Pierre-Antoine Champin: +1
  Gregg Kellogg: modulo key ordering
  Dave Longley: +1 modulo gregg’s comments
  Rob Sanderson: +1
  Ruben Taelman: +1
  Harold Solbrig: +1
  Adam Soroka: +1
  Benjamin Young: +1 modulo gregg’s comments
  Ivan Herman: +1
  Resolution #4: Update api document to be in line with syntax for json datatype, test descriptions, and “canonicalization” algorithm (modulo key ordering)
  Dave Longley: (it is important to match JCS … and hope it sticks in the future)