Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decentralized extension is not discussed #502

Closed
shigeya opened this issue Dec 14, 2020 · 6 comments · Fixed by #514
Closed

Decentralized extension is not discussed #502

shigeya opened this issue Dec 14, 2020 · 6 comments · Fixed by #514
Assignees
Labels
pr exists There is an open PR to address this issue

Comments

@shigeya
Copy link
Contributor

shigeya commented Dec 14, 2020

In Sec. 4.1 Extensibility,

  1. Representations MAY define other extensibility mechanisms including methods for decentralized extensions. Such extension mechanisms MUST support lossless conversion into any other conformant representation.

There is no discussion on what "decentralized extensions" is anywhere in the doc.

@kdenhartog
Copy link
Member

From my understanding the purpose of this statement is to allude to the idea that representations that support the ability to extend through the representation, (e.g. JSON-LD with additional contexts) then the representation can utilize these mechanisms without registering all of the extension properties as long as they can be losslessly converted to other forms.

I'm thinking this may be better worded as

Representations MAY define other extensibility mechanisms. Such extension mechanisms MUST support lossless conversion into any other conformant representation.

Looks like this text came through agreement between @msporny and @talltree in this comment #241 (comment)

Would be good to have them weigh in on it as well.

@kdenhartog kdenhartog self-assigned this Dec 15, 2020
@msporny
Copy link
Member

msporny commented Dec 17, 2020

@kdenhartog is correct, but it was really a WG consensus decision to allow representations to provide additional extensibility mechanisms. Some some minor wordsmithing to his suggestion:

Representations MAY define other extensibility mechanisms. Such extension mechanisms SHOULD support lossless conversion into any other conformant representation.

The only change is from a "MUST" to a "SHOULD" -- remember that when developers add properties in JSON that they do not have to register them and they can make those properties do things that might not losslessly convert to other representations.

To be clear, I'd be fine with a "MUST"... but the JSON-only folks in the group may protest because we're imposing things they don't have to deal with in JSON-only land.

@peacekeeper
Copy link
Contributor

I agree with the above, the idea has always been that representations can "extend" the data model in a representation-specific way, without necessarily requiring the use of the registry. If the registry is not used, then lossless conversion is not guaranteed, but you are free to use any representation-specific feature you like. This approach was taken in part to allow the open world model of JSON-LD/RDF that allows extensibility without requiring a central registry.

We changed MUST to SHOULD in #465.

How about rewording as follows?

Representations MAY define other extensibility mechanisms including ones that do not require the use of the DID Core Registries. Such extension mechanisms SHOULD support lossless conversion into any other conformant representation.

@kdenhartog
Copy link
Member

+1 I'm good with that @peacekeeper. It addresses the original concern more precisely than my original proposed text and aligns with the normative examples that are current. Seeing as we made the normative change already, this seems largely editorial at this point as well.

@shigeya
Copy link
Contributor Author

shigeya commented Dec 21, 2020

I'm good with the change by @peacekeeper. thanks.

@kdenhartog kdenhartog added the pr exists There is an open PR to address this issue label Dec 21, 2020
@msporny
Copy link
Member

msporny commented Dec 27, 2020

PR #514 addresses this issue, which will be closed once that PR is merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr exists There is an open PR to address this issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants