Closed msporny closed 3 years ago
@msporny @OR13 actually the idea of "representation (-specific) data models" does resonate with me a bit... A few months ago I suggested that we should have a "common data model" and multiple "representation data models". But in my mind the latter was a superset of the former (not a separate bucket), so not sure if that's aligned with your thinking.
For reference, here's the diagram I was using back then:
But in my mind the latter was a superset of the former (not a separate bucket), so not sure if that's aligned with your thinking.
Yes, aligned w/ my thinking -- but I was trying to not introduce yet another concept into the specification. Even if we were to add the concept of a "DID Document data model", and "Representation data models", we would still need yet another data model, which is shared among produce
calls. @OR13 described it as productionOptions
, which would contain stuff like @context
. I was thinking more along the lines of representationEntries
which would contain things like @context
.
I think we're circling around the same concepts, but at this point, we need to settle on a way of talking about it in the spec.
What I could do is clean this PR up and pretend we didn't have the discussion above... raise an issue, and then in a separate PR try to make the whole "different data models and/or productionOptions and/or representationEntries" work across the data model and all representations? In other words, make a pass to get stuff in a decent shape to then make these changes above easier to see/reason about. Thoughts?
Lets stick to discussing on issues and keep PR reviews about actual changes... I have moved my comments here: https://github.com/w3c/did-core/issues/664#issuecomment-780647353
Substantive, multiple reviews, changes requested and made, objection raised by @peacekeeper and addressed via spec text change, no remaining objections, merging.
This PR is a fairly significant restructuring of the JSON-LD section. All the previous normative statements are more or less still active, save for the ones that are handled by other parts of the specification. I don't think implementations would need to change based on the modifications in this section, but I'm still marking it as a substantive change so people put a bit more diligence into reviewing it to make sure it does everything important that was being done before while attempting to simplify the language a bit (and cover some edge cases/advisements).
Preview | Diff