Re: Thoughts on explaining our Grand Compromise

+1. This is a key point to what we agreed to last week. 

The registry is about writing things down in a way that you can depend on other people know what to do (or at the very least, what to avoid) when they see the new pieces you’ve put in there. Nothing stops you from doing whatever you want locally, or with a bilateral agreement between parties. If that’s within your model, then go for it. 

But if you want everyone else to be able to deal with your stuff without weird code paths? Then for this spec you need to register with all of the appropriate pieces so that different processing models can manage it. And all of the processing models need to have rules of how to map new and unknown items into their model.

Similarly, if you want to use your own custom representation based on LISP s-expressions with symbol names in Hangul... well then, nobody’s going to stop you. But if you want to make sure that other processors can deal with your output, and you want to deal with everyone else’s input, then you are going to need to define how that maps to the model. 

I personally think that we’ve landed on a particularly powerful model here. We’ve got something that at its core is an object model based on the simplest JSON data types. These are powerful precisely because they are simple and common. These can be translated into a number of different things, including representations like JSON-LD that allow for really powerful processing and representations like CBOR that let us get deep into the IoT world.

Each of these representations, both the ones we define within the core spec and any that come later, are going to need to write their rules as both producers and consumers. This is what guarantees the loss-less bidirectional translation between formats. This is what makes the abstract data model :real: and not just academic as it is with so many other specifications. 

 — Justin

> On Feb 4, 2020, at 6:27 AM, Dan Burnett <daniel.burnett@consensys.net> wrote:
> 
> After talking with some folks on the last day last week, I think there is an easier way to explain the compromise we reached at last week's face-to-face meeting.
> 
> Registries are not about extensibility; they are about interoperability.
> 
> In our case, any user of any given DID Document representation may extend its set properties in any way they wish.  However, such an extension will only be _loss-lessly interoperable_ with the other representations if the extension is added to the registry according to the rules of the registry, including specification of the extension and any required rules for mapping to the other representations.
> 
> Nothing in our agreement is intended to in any way restrict the ability of a user of a representation from adding new properties; it is just that there is no guarantee of loss-less interoperability with other representations if the extension is not added to the registry.
> 
> 
> So we could have an Extensibility section in the spec that describes this, with a pointer to the registry process and pointers to individual subsections for each representation that explain the variety of ways in which DID Documents in that representation can be extended.  For example, in JSON you can just add a new property; in JSON-LD you can add a new context.  Those subsections will warn that this does not guarantee loss-less interoperability with other representations unless you follow the registration (registry) process.
> 
> -- dan (speaking as himself, not as chair)
> 
> p.s. if this is confusing or controversial to anyone, pretend I didn't say it :)
> 
>

Received on Tuesday, 4 February 2020 16:28:20 UTC