search

w3c / did-core

W3C Decentralized Identifier Specification v1.0
https://www.w3.org/TR/did-core/
Other
405 stars 94 forks source link

Describe `@context` as JSON member in JSON-LD production/consumption. #610

Closed peacekeeper closed 3 years ago

peacekeeper commented 3 years ago

Okay I know how controversial this will be, considering the discussions around my diagrams in https://github.com/w3c/did-core/pull/596 and https://github.com/w3c/did-core/pull/597), but I have to try.

This changes the language around @context in the JSON-LD production/consumption sections to treat it primarily as a member in a JSON object (concrete DID document representation), rather than an entry in the INFRA map (abstract DID document data model).

Explanation:

The JSON-LD production section as it's currently written seems to contradict itself. First it says

"The DID document MUST include the @context entry."

but then it says

"This entry [..] could be present [..]. If the entry is present" [..].

I am pretty sure the intention here is to say that @context MUST be present in the JSON-LD representation, and it can be preserved as an entry in the abstract data model, but it is definitely NOT a REQUIRED entry in the abstract data model (it's not a Core Property). This PR clarifies this.

As an additional indication to support this, look at the examples in this section. They are JSON examples, not INFRA examples.

Preview | Diff

msporny commented 3 years ago

I'm not sure why this would be controversial unless I'm missing some nuance... it fixes a few bugs in the JSON/JSON-LD production rules. That it's not controversial makes me think that it's not addressing the point of contention.

In other words... where does @context come from? IIRC, there is something that is not the ADM that produces it... but people are free to dump it into the ADM if they want to... especially the JSON folks, because they can't differentiate between @context and @foobar... treating them the same, by preserving them in the ADM.

iherman commented 3 years ago

I'm not sure why this would be controversial unless I'm missing some nuance... it fixes a few bugs in the JSON/JSON-LD production rules. That it's not controversial makes me think that it's not addressing the point of contention.

@msporny I believe the controversy comes from the reactions in #596 and #597 which seem to say that the ADM MUST include the @context values. Obviously, the @context MUST be in the serialization if this serialization is in JSON-LD, but that should be the only MUST in this respect. Methods may decide to store a context, may decide to pick up the value from the registry for non-core terms, or ignore them altogether because that particular method works only in JSON or in CBOR. How this is done is implementation dependent.

The latest commit goes in this direction indeed.

peacekeeper commented 3 years ago

I agree with @iherman 's comment. If there's agreement that the ADM does not HAVE to contain @context in order for production to work, then maybe there's less controversy than I thought.

iherman commented 3 years ago

In other words... where does @context come from? IIRC, there is something that is not the ADM that produces it... but people are free to dump it into the ADM if they want to... especially the JSON folks, because they can't differentiate between @context and @foobar... treating them the same, by preserving them in the ADM.

Strictly speaking, that is not true. The end of §6.2.2 (on JSON consumption) has an extra note:

Note that the @context object member, if present, will not have additional processing applied to its value, which will be added verbatim to the data model.

Not sure it makes all that big difference, but clearly the spec gives a special role to @context already.

msporny commented 3 years ago

Editorial, multiple reviews, changes requested and made, non-blocking concerns raised, merging.