Add diagram "production and consumption".

[peacekeeper]

For the "Representations" section:

Diagram illustrating how representations of the data model are produced and consumed, including in JSON, JSON-LD, and CBOR.

---

Preview | Diff

[TallTed]

As with https://github.com/w3c/did-core/pull/595#issuecomment-772845778...

Needs much more detailed longdesc description

[rhiaro]

Agreed with @OR13 .. there are terms in the JSON-LD representation which are not in the context, making this representation invalid, per:

Producers SHOULD NOT produce DID documents that contain properties not defined via the @context.

And also need to improve a11y, for #118

[peacekeeper]

@rhiaro thanks, I agree. I just pushed an update that fixes this, and the JSON-LD representation should now be valid. Do you agree?

[OR13]

This diagram remains incorrect:

https://github.com/w3c/did-core/pull/596#issuecomment-774794739

I will not approve this PR until:

@context is included in the DID Document INFRA map that is used to produce the JSON-LD....

Alternative solutions:

1. split the diagram up, so that did+json and did+cbor are produced from an ADM that does not have an @context but did+ld+json is produced from an ADM that contains an @context.
2. include @context in the ADM, but not in the JSON or CBOR representations
3. remove the incorrect diagram regarding JSON-LD production.

[iherman]

@OR13

... for example, when serializing a DID Document with extensions for PGP...

The abstract data model would need to contain the @context for the registered extensions, such as:

https://or13.github.io/lds-pgp2021/#did-document

Hm. If I am overly pedantic, then I do not agree...

In my view, the ADM does not include the context. The ADM representations for that particular DID includes a term (PgpVerificationKey2021) that is not defined as a bona fide core DID term. The ADM "processor" (method, whatever) must then consult the registry, locate the PgpVerificationKey2021 entry in the registry, find the corresponding context reference, and must add that @context to the generated JSON-LD. This does not mean that the context, per se, is part of the data model, it means that there is a well-defined course of action for a processor to handle the non-core terms which involves the registry and the generation of additional @context statements. That is very different. (Whether the processor does this registry look up on the fly, or whether it has a cached version, becomes an implementation detail from the point of view of the DID Core spec.)

This process is not really described in the spec (and it probably should not, this should probably be the subject of the final version of the method specification when it comes). Maybe the spec should at least hint at this (oops, we have one more day to add a PR if we want to have that...:-)

I may agree that something about this may have to be part of the diagram but I am not sure: the diagram may become very bloated.

You may try to convince me not to be that pedantic:-)

[OR13]

@iherman https://w3c.github.io/did-core/#production-0

See the current normative requirements for JSON-LD production.

Its not possible to produce application/did+ld+json for a "DID Document: INFRA<MAP>" without it containing an @context... I'm sorry this is confusing, but is pretty fundamental to consensus regarding the viability of the ADM... without my assertion being true, we don't have an ADM representation for JSON-LD, and we don't have consensus on the ADM at all... I recall making this point a number of times on WG calls, and my understanding of consensus has been captured in @peacekeeper 's image here:

[peacekeeper]

@jricher and @iherman are correct, the ADM does NOT need to contain @context or other representation-specific entries. I believe @OR13 's and @msporny 's characterization of the conclusion of the ADM discussions is inaccurate.

What we agreed on was that unknown entries including representation-specific ones such as @context can be preserved in the ADM, e.g. when you first consume JSON-LD and then produce JSON, then you will still have the @context. Personally I still believe this is a big mistake, but that was the agreement. This is why my diagram in https://github.com/w3c/did-core/pull/595 shows @context as a representation-specific entry in the ADM.

However, this does NOT mean that @context MUST be present in the ADM when you construct an instance of the DID document data model from scratch (or obtain one as a result of the resolve() function), and then want to produce a JSON-LD representation from it.

I'm very surprised to hear that this is being proposed now.

If that's your position, then you are suggesting

1. Either, that at the time when you construct an instance of the data model, you must already anticipate which representations (current and future) you may possibly want to produce from the data model later.
2. Or, even worse, that you need to populate the ADM differently for each representation (this is what @OR13 seems to propose in https://github.com/w3c/did-core/pull/596#issuecomment-775245040).

Both approaches would render the concept of an "abstract" data model absurd. Both are likely to break as soon as another representation such as XML or YAML is added.

[OR13]

As you can see in https://github.com/w3c/did-core/pull/610 there is clearly a misunderstanding regarding JSON-LD DID Document Production and Consumption.

The problem is compounded by diagrams that appear to look like JSON....

It is true that an @context might be internally represented differently than INFRA when the document is constructed from scratch.... it is FALSE that the the ADM will represent the @context as something other than an INFRA when it consumes a serialized JSON-LD Document.... it is also false that consuming a JSON-LD document somehow "looses the context information"...

In other words... the reason the diagram is wrong is that consuming JSON-LD with an @context means it is stored in the ADM (somehow)... full stop.

This makes the diagram false if it contains a consumption arrow for JSON that includes an @context or $schema and the ADM does not show those values... in the same way that the diagram would be false if it conveyed that properties were dropped as a result of consumption and production.

A separate problem with the diagram is that showing JSON-LD consumption and production require preserving @context but the same DID Document being produced and consumed in JSON might not....

This is a function of having 2 representation... and is not solved by pretending that the same information in the ADM can support both... for example.. the diagram implies that somehow JSON->ADM->JSON-LD is possible... but its not... we have proved this... because the ADM cannot know the context for members in JSON..... and no amount of. "I think there is a way" is going to make it into the spec at this point.

So the diagram is confusing / wrong on 2 fronts.

1. consuming a JSON-LD Document is not a lossy process ...@context is preserved (somehow).
2. consuming one representation and producing another representation MAY BE a lossy process depending on the representation... for example CBOR integer keys may be lost, other fancy representation specific stuff may not survive the ADM, and some methods will decide that dropping an @context is somehow useful (even though its not)

Part of having an ADM means the individual representation features might not be respected in other representations... to mitigate this, we adopted several resolutions regarding consumption and preservation of unregistered properties.

This PR attempts to undo those resolutions with an image that is misleading, and should not be accepted.

[msporny]

Part of having and ADM means the individual representation features might not be respected in other representations... to mitigate this, we adopted several resolutions regarding consumption and preservation of unregistered properties.

Found the meeting where this was discussed:

https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-11-05-did#section2

@peacekeeper, could you please point out where we agreed to what you're suggesting? Perhaps it happened in another meeting?

[TallTed]

@OR13 - There are several small but possibly troublesome typos in your last comment; at the least, they cause a hiccup in reading and trying to understand relatively important details. In most (I think, all) of these, and has replaced the word which belonged there (mostly if not all as or an). I think I figured out what was meant in all cases, but it would be best if you could review and correct the typos in your comment...

[iherman]

The issue was discussed in a meeting on 2021-02-11

• no resolutions were taken

View the transcript

### 2. production and consumption issue _See github pull request [#596](https://github.com/w3c/did-core/pull/596)._ **Manu Sporny:** There are 2 that have raised the question around ADM again … markus, would you like to provide a background on both of these PRs and the current concern? **Markus Sabadello:** one of these PRs, production and consumption … trying to show how production and consumption works and what the relationship is between the data model and the individual representations … the data model defined in section 4 and the representations in section 6 … the data model we define as an infra map … not json, not cbor, not xml, it's infra notation … the diagram is attempting to show how this abstract data model by going through a production process gets to a concrete representation in json-ld, json and cbor … that's it, the discussion and controversial aspect is around whether `@context` is included in the ADM … if ADM has to be present in the top left corner in order to produce the json-ld representation … that's the discussion > *Orie Steele:* its not about production... its about consumption... the consumption arrow is where the error is. **Markus Sabadello:** I think the consensus after the ADM discussions was the data model, the infra map, can hold `@context`, or other representation specific entries, but it doesn't have to be there … this diagram is trying to show the simple case where the data model contains core properties and other representation specific entries they get added in individual representations **Orie Steele:** i'm one of the people who doesn't think that this is a simple diagram … the consumption arrow is the problem … the production arrow is fine … how methods choose to represent context internally before production occurs, is up to them … context is a representation specific concept … consumption rules we have spent time talking about preservation of properties an dthe fact that multiple representations means that unregistered properties are all preserved … the arrow violates the WG consensus … it sounds like `@context` must be present in the ADM to produce json-ld. I'm not saying that … this picture implies somehow you can consume json-ld and lose an `@context` … we've admitted we're going to conserve all properties … I'll object until we can fix that visualization … on markus' original point, `@context` doesn't need to be in the ADM for production … but if you're consuming json that contains a member into the ADM and somehow losing it, that is a problem **Manu Sporny:** +1 what orie said … it's a difficult balance … what we're doing here is putting 3 different production/consumption things together > *Justin Richer:* for what it's worth, I am in favor of markus_sabadello 's diagrams and do not agree with Orie 's changes. **Manu Sporny:** because the diagram is trying to show production and consumption across multiple representations we should at least put `@context` in here because in this way, even in consumption in this way, you'd have `@context` … the change request is to put `@context` in the ADM … it makes it possible for the reader to ask the question why is `@context` disappearing in production here … and not here > *Orie Steele:* I would not put ``@context`` in the ADM... its confusing... I would split up the diagram **Manu Sporny:** it could also be that they raise the question fo wait a second you just consumed something where did this `@context` come from? … I think there are down sides both ways … but the way it is currently proposed makes it seems like `@context` appears out of thin air … we can't propose that as how this thing works in general **Markus Sabadello:** I made another version of this diagram … a subset of the other diagram that doesn't show all the production and consumption at the same time … but shows what happens when you consume the json-ld, and `@context` is preserved, and you produce a plain json representation and the `@context` is still there … this is the agreement we had after the discussion … I still think it's a mistake, but that's what we agreed > *Orie Steele:* A series of diagrams seems more helpful **Markus Sabadello:** I think it's more important to show a diagram that starts with a data model that does not contain any representation specific entries … if we put a diagram like this in a prominent space, people would ask why we have something represent specific in an ADM > *Ivan Herman:* +1 to markus_sabadello **Markus Sabadello:** we could have two diagrams … one that looks kind of like the one in the PR and in addition something like this … that shows preservation of the entries **Brent Zundel:** in any simple diagram of a complex system you're going to be making generalizations and making things less precise … I think either we clarify with the second diagram that says in this specific case this is what the spec text says … or add a sentence that says this diagram is a simplified visualisation and pay attention to spec for specifics **Manu Sporny:** +1 to what brent said … and +1 to this diagram, I like it much better … having a series of diagrams will be easier for people to not get confused over … I was going to say in this diagram I'd be fine also with the second thing eliminating `@context` … I know that's controversial and some people would disagree … it is an issue with round tripping … if all of us can look at this diagram and say we're fine with that being in the spec I think we're done **Orie Steele:** I think a series of diagrams would help … we need the other picture. This picture works for json-ld production and consumption … deleting `@context` will work for json production and consumption. Maybe there's a CBOR version to show as well … It'd be better to tackle the complex case of what happens if you start with json and you want to produce json-ld in a diagram that's just about that … as opposed to a diagram with 6 arrows and hiding what's going on … that's confusing … as far as manu's proposal for allowing you to produce did+json that drops a property, that violates the consensus of the WG … but I'm in favour of a picture of this that's just vanilla json that never has an `@context` in it ever **Ivan Herman:** I am sorry but I don't like that one … if I am coming from the outside what I see is that the application did+json and did+ld+json are exactly the same … if I know a little bit about json-ld then I don't know what the `@context` does and plays what role on the right hand side … If I remember well, we separated the representation specific properties form what is in the core set … what about making some sort of a diagram which has the data model as it is now … without the context … and in that box in the upper left, a separate entry somehow for representation specific properties … where the context is present … we do separate these things … context is specifically called out as a special thing in the spec > *Shigeya Suzuki:* Isn't it possible to keep representation-specific property as part of didDocumentMetadata ? (I mean, split the upper-left box)... > *Shigeya Suzuki:* ah, that's what ivan is saying I guess... **Ivan Herman:** in the representation on the data model there is something else that should be part of the diagram … when I produce the json I use it or don't use it … and things become clearer … but merging the two things for me is a mistake **Justin Richer:** +1 to ivan … the underlying problem people seem to be having with the original diagram is that the json-ld crowd sees this as okay so obviously you're starting with the thing in the lower left and everything else is derivative and you're dropping properties … that's not an accurate reading of the diagram … which means the diagram is misleading if people can read it that way … what this is trying to show is that there is a DID doc which is the thing in the upper left > *Orie Steele:* I agree with Justin... the diagram is confusing. **Justin Richer:** that can go in and out of representations using the production and consumption rules specific to those representations … I like ivan's idea of putting the representation specific properties into a separate bucket in the ADM … we had long discussions about these being different things … than did doc properties … I think that would help to tell that story > *Orie Steele:* I also agree with Ivan and Justin's proposal to store `@context` in the ADM in a separate bucket. **Justin Richer:** because I completely agree that the other one that has `@context` in both the json-ld and json isn't telling an accurate story either … it is telling a limited story of limited usefulness to make one small point … about carrying this `@context` value through … if you're producing did+json then `@context` is a meaningless field, which will be held next to the data model, not in the data model … and to go in the opposite direction to produce ld+json from a json source, you would need to create the context probably based on that field that was passed in … but potentially not … because there will be plenty of cases where the plain json has no semantic labelling in it … and that needs to be added by the ld processor on production … I get where the LD community is coming from, but that's not the story I believe markus was trying to tell with the original diagram … which is why I am against the proposed changes **Markus Sabadello:** I can update the PR with two diagrams based on that … what's most important for me is to make the point that you can start with the instance of the ADM that does not contain any representation specific entries and then produce all of the conformant representations from it > *Justin Richer:* +1 to get rid of the consume arrows **Markus Sabadello:** maybe orie and manu would be okay if this diagram did not contain the consumption arrows … or it would be greyed out and this would show that based on the ADM you can produce all of these … and as a second diagram we could have representation specific entries that are preserved … I can also do what ivan said, to illustrate that this `@context` is part of the data model but is representation specific entry … I could do that if it's acceptable to have two diagrams … the second PR that's open is about the same thing … all the concerns we heard apply equally to the other PR … which is another diagram more to do with resolution … but same underlying issues, I could also split that into two diagrams > *Brent Zundel:* what if we added a description to the diagram that says: "This diagram illustrates how the abstract data model might be used to produce each representation. For specific details on the production and rules for each representation, please refer to ..." **Orie Steele:** Splitting consumption and production up would help a lot … in the production case, going from a box that has context floating next to the ADM to a json representation that does not contain a context, that's very valid and exactly what we agreed to in the WG … if we remove the consumption arrows we'll be on the way to solving issues … we already put `@context` in its own special box … it's a property that is a representation specific property allowed in the ADM … some of the language using was using is challenging because we only have one bucket to put ADM entries, so we're shoving representation specifc entries and DID doc entries into the same bucket … at this point we're stuck on that path … but it doesn't mean we can't have a nice clean picture of production and consumption that is respective of the native representations … I don't agree that it's an LD thing … I think it's a JSON preservation of properties in a consistent manner > *Justin Richer:* if it's not an LD thing then just drop `@context` :) > *Manu Sporny:* if it's not an LD thing then just drop foo :) > *Manu Sporny:* ^^ see the problem w/ that line of argumentation? **Orie Steele:** if I add foo or $schema and do consumption then production, I expect those properties to preserved by JSON … I care more about the json rules making sense … json needs to preserve properties when being consumed and produced through the ADM **Manu Sporny:** we're getting to something maybe workable … there are normative statements int he spec that are probably going to have to change … I think it might be for the best … our data model keeps thinking that, sort of asserts that the DID doc is the only thin you can express and that's the root … with the work on the resolution section and this stuff I think it's clear that we want more than one bucket … the data model is capable of expressing a number of things - metadata structure, DID doc, Verificaton method structure … or a bucket for representation specific properties/entries … as long as the group is okay with this direction, I can make some substantive changes that create multiple buckets … make the ADM a bit more generalized … and I think that will address a number of issues throughout the spec … I think there's something workable here … markus if you rework the diagrams … and I work on some of the text … we may be able to come to something more generalized that can be applied more cleanly across the entire spec … +1 for the changes requested … and making the diagrams more specific > *Orie Steele:* selfissued is not here... but he would agree with me :) **Justin Richer:** respond to the 'foo' property thing … this is, as has been previously argued many times, as we've talked about, it really is a different kind of thing … say your source doc is coming in in json and has a property named `@context`: true … this is acceptable, it gets dropped into the ADM with a property named `@context` with a boolean value of true … all of that works … when you go to produce that into ld+json … everything is legal so far … when you go to produce ld+json that LD producer has to supply a context field and it has to have a valid value … and it is programmatically going to have several sources of information for the value of that field … extra properties dumped into the data model that the consumer didn't know how to do anything special with, like `@context`, is going to be one of those … the problem is that the LD produce absolutely has to understand the `@context` property if it shows up in the ADM … and be able to process it with a correct value … so this is not to say this is just about property preservation … it's not … pretending that it is is not helpful to the conversation … what we're really talking about here is how do we create an LD json document … when we have different sources of information for what goes in the context field … which is semantically significant to json-ld, but not necessarily to anybody else … all of these examples of what you want to happen are coming form places where you're getting good data … but you're not guaranteed to get good data from other implementations, other representations … this is a dangerous road to walk down > *Manu Sporny:* I disagree with Justin, but won't belabor the point -- the WG has discussed this many times, and has shown how `@context` is useful in JSON-only. We're just not going to agree on this. > *Orie Steele:* I obviously don't agree with justin_r, luckily we both appear to agree to the application/did+json production and consumption rules in the spec. > *Manu Sporny:* Yep, agree, let's just leave it there. > *Justin Richer:* apparently we disagree on what the WG has agreed to as well **Markus Sabadello:** I will try to work on updates to the diagram … manu I was surprised to hear you think normative statements have to change … I think we're already saying this n the spec … we say the data model can contain two kinds of entries … I thought that was what the third diagram was bout, which is less controversial … in an open PR that already shows the specification today, that the data model can hold the core properties and also representation specific entries … I look forward to any suggestions on how to improve also the text … I want to show the other diagram this is controversial but the same underlying topics > *Justin Richer:* +1, I don't see any need to change normative statements from these diagrams **Markus Sabadello:** the same thing as before, production and consumption fo different representations, but adds a resolution here … resolve which returns ADM and `resolveRepresentation` which returns a representation … probably the same issue here, which if you consume a json-ld the `@context` should be preserved … so i made another version, one of the sequences is you `resolveRepresentation` you get back json-ld, consume that and produce json with `@context` preserved … I can also try to update this PR with input that was given **Manu Sporny:** +1 to that diagram, very helpful … I'd be good with that … The normative statements I'm talking about, we just want to be crystal clear about this discussion … in section 6.1 we say: > *Manu Sporny:* We say this in 6.1 currently -- "The representation MAY define representation-specific syntax that can be stored as entries in the data model. These entries are included when consuming or producing to aid in ensuring lossless conversion." **Manu Sporny:** when we say data model we have other language that says the data model is the DID doc > *Orie Steele:* "stored as entries in the data model" => `DID Document : INFRA

[peacekeeper]

the diagram implies that somehow JSON->ADM->JSON-LD is possible... but its not... we have proved this...

@OR13 it should be possible if the JSON only contains registered properties. If you have a proof that this is not possible, I'd love to see it. Enabling this was the original reason why we introduced the registry (and the requirement to supply a JSON-LD context for each registered property) at the Amsterdam F2F.

If the JSON contains unregistered properties, then I agree this is not possible.

[peacekeeper]

In an attempt to unblock this, @OR13 and @msporny would you agree with this diagram if I change it as follows:

[msporny]

In an attempt to unblock this, @OR13 and @msporny would you agree with this diagram if I change it as follows

The diagram is an improvement over the previous one. The diagram is still not clear wrt. where @context comes from. I'm trying to add language in the Editorial pass to provide a bucket, expressible via the data model, where you can store/retrieve representation-specific entries during the consumption/production process.

Do you have the diagram above available in an editable format? It would be easier for me to just show you what I'm talking about.

[OR13]

@peacekeeper I would agree to the diagram in:

https://github.com/w3c/did-core/pull/596#issuecomment-779276110

IF and only IF:

A. @context where present in the entries prior to JSON-LD production. B. JSON-LD production was defined as a process that took an @context / other representation specific entries.

we cannot create information from nothing...

we probably should have defined functional signatures for production and consumption ages ago....

A. produce(adm: entries) => Buffer (JSON-LD) B. produce(adm: infraMap, options: infraMap ) => Buffer (JSON-LD)

I would accept either....but B would require significant changes to the spec.

It sounds to me like @peacekeeper might prefer B... in which case production would look like this:

const produceJsonLd = (entries: object, options: object) =>{
  return JSON.stringify({...entries, ...options.requiredMembers});
}

We would be required to define options in did core, and requiredMembers infra map... and it would be required to include an @context for JSON-LD and a $schema for JSON Schema.

[peacekeeper]

A. @context where present in the entries prior to JSON-LD production.

Then how does it magically get removed to produce the plain JSON representation? Anyway, I think adding such requirements won't work, since that would break the concept of an abstract data model.

Do you have the diagram above available in an editable format?

I'm attaching the source file, yes maybe you can draw your perspective on how it should work..

production-consumption.zip

[OR13]

A. @context where present in the entries prior to JSON-LD production.

Then how does it magically get removed to produce the plain JSON representation? Anyway, I think adding such requirements won't work, since that would break the concept of an abstract data model.

why would you add an @context and then try to produce application/did+json ?

...also... @context and $schema are legal members of JSON.. you can tell because JSON-LD and JSON Schema are BOTH JSON... you are introducing harmful complexity in an attempt to redefine what JSON is in this WG.

[msporny]

@peacekeeper now that we have the concept of a representation-specific entries map can you please update the diagrams to include that (noting that @context comes from that map for JSON-LD production). That should allow us to get these diagrams integrated. I will also note that the diagram in the data model section is now wrong (because it contemplates @context in the DID Document data model, which is now incorrect).

[iherman]

I will also note that the diagram in the data model section is now wrong (because it contemplates @context in the DID Document data model, which is now incorrect).

Because I have re-created this diagram in draw.io, I guess I "own it" now... I will look into this.

[iherman]

I will also note that the diagram in the data model section is now wrong (because it contemplates @context in the DID Document data model, which is now incorrect).

Because I have re-created this diagram in draw.io, I guess I "own it" now... I will look into this.

See https://github.com/w3c/did-core/pull/692.

[peacekeeper]

Hmm this really becomes harder to draw now, but how do people feel about this?

[talltree]

@peacekeeper I like this version very much. You did a good job of adding representation-specific entries. Spot on. Nice job.

[OR13]

@peacekeeper that picture is better, but is till not completely in line with the spec... for example:

https://w3c.github.io/did-core/#data-model

production and consumption are defined in terms of the "DID Document entries"... so sadly... this diagram is not consistent with those section... I hate to be pedantic, but this is still a problem.

production and consumption are not defined in term of "representation specific entries"...

They are defined in terms of DID Document entries... The new picture implies that representation specific entries are some how no did document entries... if thats true the production and consumption sections need to be rewritten.

For example, see https://github.com/transmute-industries/did-core/blob/main/packages/did-ld-json/src/did-ld-json.ts#L55

its possible that if you cover one eye and squint, the spec is implying that

1. DID Document = <DID Document Entries + DID Document Representation Specific Entries>

or...

2. DID Document = <DID Document Entries>,  <DID Document Representation Specific Entries>

the spec says 1, this diagram implies 2.

[peacekeeper]

@OR13: After merging @msporny 's PR https://github.com/w3c/did-core/pull/679, the section on Production and Consumption now says

A conforming producer MUST take a DID document data model and a representation-specific entries map as input into the production process.

I.e. the produce function now takes two maps as input, and the consume function returns two maps as output. That's what the new diagram in this PR here https://github.com/w3c/did-core/pull/596#issuecomment-784323901 is trying to show.

I agree this is now inconsistent with the data model diagram. @iherman is working on updating that in https://github.com/w3c/did-core/pull/692.

[OR13]

related: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-11-05-did#resolution4

[OR13]

I would approve this, if the upper left hand corner looked like:

[OR13]

^ the data model must be presented consistently.

[iherman]

The issue was discussed in a meeting on 2021-02-25

• no resolutions were taken

View the transcript

### 1. Diagrams _See github pull request [#596](https://github.com/w3c/did-core/pull/596), [#597](https://github.com/w3c/did-core/pull/597)._ **Markus Sabadello:** there are two open PRs with diagrams that I was working on … one is [#596](https://github.com/w3c/did-core/pull/596) … on production and consumption … one on resolve and resolveRepresentation … 597, I have not worked on updating that yet … I have tried to update the production and consumption one … I came up with this version … latest attempt maybe not perfect, but how close is it to what people want to see? … tries to implement this separation of the maps that we're saying we're passing into the production function and getting out of the consumption function … and the did document data model and representation specific entries as a separate map **Manu Sporny:** this is not necessarily aligned with where I thought we were going … its' confusing because the bottom one looks like it's just using the representation specific entries … some changes … if you take did document data model at the top and figure out how to move it into that dashed box … and representation specific entries, strike json-ld, and move into the dashed box below … and do a larger dashed box around both … and have produce and consume go from that would solve the issue for me **Markus Sabadello:** *live edits diagram* **Manu Sporny:** it does dodge some of the questions, but addresses my concern, if everyone agrees **Markus Sabadello:** I can live with it > *Ivan Herman:* +1 with these changes **Orie Steele:** what was proposed is consistent with the current diagram that has been merged into did core … the upper left hand box with dashed lines is already represented in did core under the data model section … i'd be fine if we used the existing diagram and didn't add another diagram that in some ways conflicts … the existing diagram we have in did core is acceptable for me … as a result of consumption … i'm struggling why we should show different pictures of the same data model … almost there, stop representing the data model differently in different diagrams … use the same diagram for each of them > *Shigeya Suzuki:* While I almost agree to the diagram... +1 to Orie's opinion > *Shigeya Suzuki:* (reuse same diagram on same concept) **Ted Thibodeau Jr.:** i'm concerned that surrounding dashed box suggests that those representation specific entries are part of all of the productions **Ivan Herman:** orie, when you talk about the diagram in the spec right now, are you talking about that one or the change that is part of another PR? **Manu Sporny:** merged few minutes ago **Ivan Herman:** you make our life difficult :-) > *Orie Steele:* I mean use this diagram: [https://w3c.github.io/did-core/#data-model](https://w3c.github.io/did-core/#data-model) > *Orie Steele:* :) **Manu Sporny:** I like where orie is going with this, we do have something already, can we reuse that … that would be better I think **Ivan Herman:** there is a difference, what markus is doing is with code extract which here is not the case … reusing the same style and colours would make sense … but it's not the same diagram … here we list some of the core properties, not all > *Shigeya Suzuki:* +1 to Ivan > *Justin Richer:* +1 this is not the same diagram, this is how we get TO that diagram (and from it) > *Ted Thibodeau Jr.:* +1 these are different diagrams for different purposes > *Brent Zundel:* +1 **Markus Sabadello:** also some similarities and differences … both show the data model, but this one here that ivan made is intended to be more generic and higher level, whereas the other has a concrete example … the other difference is that this is showing the concepts of core things and registered extensions and unregistered extensions, which are irrelevant in the other diagram which is about production and consumption > *Drummond Reed:* +1 to the diagram we are seeing now on "production and consumption" **Markus Sabadello:** using similar colours and style, I'd be happy to make an attempt to do that **Manu Sporny:** orie, would you be okay with that? I buy the argument that they're slightly different.. would you be okay that kind of set up? **Orie Steele:** we have a resolution that hasn't made it into the spec yet around ignoring and consuming properties … somewhat related to what we're talking about here … this diagram that's showing concrete production and consumption for three representations … aligning the colours is a good idea … dangerously to represent the adm abstractly and concretely in slightly different ways … an issue of colouring and consistency … and boxes coloured one way in the abstract sense, should show how properties are preserved during consumption should show up in those boxes … when you consume your properties are going into one of many different coloured boxes, and when you produce they're coming out of the coloured boxes and going into one representation … I like the image in did core right now, and this one doesn't look like that … the subtle differences are harmful … we should use the same labels … representation specific entries, core representations specific entries … all of the term labels should be the same **Manu Sporny:** I agree with what orie is saying in general … is markus willing to give that a shot? … Ted raised that it make sit look like you use all those things to produce and consume … that's why I was saying there's a bit of a handwave that is okay … you can > *Orie Steele:* For the record, I am fine with the "content" of the diagram, just concerned about colors / labels **Manu Sporny:** nothing to say that an application can't go into these boxes and modify them between production and consumption … I might consume json-ld, and if I know i'm going to produce json and my application feels strongly about removing @context it has the choice of doing that … we don't have anything in the spec that says you can't … we suggest that you should preserve everything … but apps can process these boxes for their own reasons … in consumption we say you have to preserve it … but we don't say you have to all the way through to production … you can modify them between those two … thats why we're handwaving a bit over this … I think that's okay because we need to get something that we're more or less okay with, otherwise this is going to keep getting blocked > *Orie Steele:* For example, you are not required to preserve prototype pollution or sql injection attacks :) **Markus Sabadello:** agree that what we have now would allow both … it would allow having @context int he representations specific entries then producing plain json, and including `@context` there though personally I don't like it I think it's allowed and possible with the spec language … what I could also do is what we discussed before to split this up into multiple diagrams where we show different flows or different ways of using this … first consumption, then production … sometimes `@context` is there, sometimes it's not … I'd rather have one diagram **Brent Zundel:** feels like we have consensus on direction … I'd also rather have one diagram … opposition to moving on to testing? > *Orie Steele:* Also for the record, when you advocate for producing application/did+json without an @context, you are advocating for incompatibility / non-interoperability with JSON-LD verifiable credentials.

[TallTed]

@OR13

^ the data model must be presented consistently.

"Consistently" does not necessarily mean "identically", at least, not in any dictionary with which I'm familiar.

The two illustrations serve different purposes, and therefore show different perspectives of the same thing, which perspectives are not inconsistent with each other, in my opinion. In yesterday's call, it sounded to me like most others are in agreement with me on this.

Perhaps you can explain how you see the two to be in disagreement with each other, which might help us figure out how to communicate the different perspectives, serve the different purposes, without that apparent disagreement?

[msporny]

I'm running out of time to merge this PR before freeze this coming Monday COB ET. I need an update @peacekeeper -- ETA? If we can't get this in before CR, it's not a big deal, it's editorial, it can go in after we're in CR.

[peacekeeper]

I pushed an updated version, based on recent conversations.

Changes:

• More aligned in style and color with the diagram in the "Data Model" section.
• Now shows how two different maps are involved the production/consumption process.