normative statements: JSON and JSON-LD representations sections #436
Conversation
Removes duplicate normative statements in introductory text in favour of more precise statements in the paragraphs which follow in the JSON and JSON-LD representation sections. Also fixes some spacing and formatting.
Normative requirements about dereferencing and and hashing contents of @context URIs are requirements on a producer rather than a consumer, so these statements have been moved accordingly. (#384) Also removes normative language around conforming to JSON-LD production rules as this is not a requirement on the consumer, but advisory.
rhiaro
force-pushed
the
rhiaro-384-normative-statements-representations-2
branch
from
6c6a29c to
bd9c247
Compare
Co-authored-by: Brent Zundel <[email protected]>
| It is RECOMMENDED that dereferencing each <a>URI</a> value of the | ||
| <code>@context</code> property results in a document containing | ||
| machine-readable information about the context. These URIs SHOULD be | ||
| associated with a cryptographic hash of the content of the JSON-LD Context as |
There was a problem hiding this comment.
Just now noticing this portion of text. Looks like it was in here before though. Do we need to say anything more about how this cryptographic hash should be associated? I'm thinking what sort of format should it be provided (e.g. hashlink, multiformat, etc) as well as what sorts of restrictions do we want to say about the hash used (e.g. MD5 or sha-1 acceptable?)
These are nitpick details that I wasn't sure if it would be better to put in here or in the did-spec-registries document. I can file the issue in the appropriate place so we can follow up on this in a subsequent separate discussion.
There was a problem hiding this comment.
I agree, and think this should go in the Registries. See also: w3c/did-extensions#146
There was a problem hiding this comment.
I'm in favor of either specifying a single hash format or removing these recommendations... this is creating complexity which I doubt it adding any value... and of course, you can just use IPFS URLs if you are concerned about this.
|
Normative, multiple positive reviews, changes requested and made, no objections, merging. |
Some rearranging of normative statements to more appropriate places, and removal where redundant (in intro/advisory sections). More detailed explanations of each in commits. #384
Preview | Diff