removing remaining references to JSON

[Sakurann]

Clarifying that "There is no such thing as vc+json", addressing #1044 and preventing future confusion like in #1088 after it was merged. As part of that clarification, it references JSON-LD spec directly wrt the processing of @context, since if the base media type is vc+ld+json, it needs to be a valid JSON-LD.

---

Preview | Diff

[msporny]

Suggested change

	valid.
	a valid document.

[msporny]

Approving, but noting that I'm a bit on the fence about removing this language, as that is how some implementations (including some of Digital Bazaar's processing pipelines), handle the VC as it is coming into or retrieved from our systems. We do, when it matters, do full JSON-LD processing, but that is not always necessary to perform. As long as we don't suggest that full JSON-LD processing is always required, this PR is fine. We might want to move a variation of this text to the implementation guide to ensure that developers know that it's ok to 1) ensure the order of the @context entries, and then 2) process as ordinary JSON, in the circumstances where you don't need to check the signature yet, or when the signature has been checked and you know that you're working w/ good data.

[OR13]

Keep in mind that if +ld+json is not registered... none of what we are doing will matter... because there will be no general guidance on processing the media types we are requesting registration for.

w3c/json-ld-syntax#415

[OR13]

I'm requesting changes until the structured suffixes details are resolved sufficiently to protect implementers from the confusion that would arise from removing these references while not defining how the suffixes are processed.

[Sakurann]

@OR13 what concrete details on the structured suffixes do you want to be resolved? multiple suffixes draft in IETF and how +ld+jwt is being processed is orthogonal to the changes in this PR and should block it.

[OR13]

@Sakurann I guess you are right, the problem will be... if +ld+json is never registered, and its the only media type suffix we rely on, then our document should not advance.

I am approving, with the hope that does not happen.

[msporny]

@Sakurann, waiting on a typo fix before merging: https://github.com/w3c/vc-data-model/pull/1182/files#r1249374162

[iherman]

The issue was discussed in a meeting on 2023-07-11

• no resolutions were taken

View the transcript

1.7. removing remaining references to JSON (pr vc-data-model#1182)

See github pull request vc-data-model#1182.

Brent Zundel: this P.R removes differentiation between JSONLD and JSON. Has relatively broad approval.
… minor changes from manu, that I agree with.
… not sure this P.R calls for much discussion, but open to any if there are some.

[iherman]

The issue was discussed in a meeting on 2023-07-11

• no resolutions were taken

View the transcript

1.7. removing remaining references to JSON (pr vc-data-model#1182)

See github pull request vc-data-model#1182.

Brent Zundel: this P.R removes differentiation between JSONLD and JSON. Has relatively broad approval.
… minor changes from manu, that I agree with.
… not sure this P.R calls for much discussion, but open to any if there are some.

[msporny]

@Sakurann, waiting on a typo fix before merging: https://github.com/w3c/vc-data-model/pull/1182/files#r1249374162

Actually, the suggestion is Editorial, and made by me, so I can just merge at this point and make the change, which is what I'll do.

[msporny]

Editorial, multiple reviews, changes requested and made, no objections, merging.

[iherman]

The issue was discussed in a meeting on 2023-07-11

• no resolutions were taken

View the transcript

1.7. removing remaining references to JSON (pr vc-data-model#1182)

See github pull request vc-data-model#1182.

Brent Zundel: this P.R removes differentiation between JSONLD and JSON. Has relatively broad approval.
… minor changes from manu, that I agree with.
… not sure this P.R calls for much discussion, but open to any if there are some.