-
Notifications
You must be signed in to change notification settings - Fork 103
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
Organize v2 context. #1511
Organize v2 context. #1511
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for taking the time to do this
93ecdd4
to
c142771
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move the JWT properties to the bottom, it's confusing to hit a bunch of JOSE properties for a page and a half before you get to any of the VC v2 properties.
We will probably want to put imported securing mechanism properties, including proof and DataIntegrityProof, towards the bottom of the document.
Other orderings are certainly possible. This change is for humans since the machines will read it the same way. The aim of this first pass was primarily a few major groupings then alphabetical ordering. That matches how I've been trying to read the file in the past and the motivation for this change. While I understand the idea of further grouping, it starts to again make it difficult to find properties and types. I had thought about putting core properties/types first then other specialized ones. But at first glance it didn't seem that great. Open to other thoughts on this. I can adapt to whatever order is used. At least some ordering is an improvement. And I'll note that |
- Opinionated but consistent organization and sorting. - Semantically equivalent to previous style. - Order is recursive and roughly follows a pattern: - JSON-LD keywords - blank line - id/type terms - blank line - jose/jwt property terms - sorted - blank line - other property terms - sorted - blank line - type terms - sorted - for TypeCredential/Type pairs, put TypeCredential first - blank line between each - Drop down and indent values to try and be under 80 chars per line.
Editorial, multiple reviews, changes requested (and no made, but @msporny isn't going to object over them), no objections, merging. |
@davidlehn wrote:
I took what you did and regrouped with the following layout:
|
@msporny Minor nit with your reordering commit (which wasn't in a PR I think?). Is dropping the trailing newline intentional? This is one of those things that tends to cause some churn due to editor settings and it's inconsistent between projects. In this case it matters since the file will be hashed. I'm on team trailing newline. A .editorconfig might help for this, for those that use that tooling. |
Nope, the deletion of the trailing new line was inadvertent. We can add it back in. |
The v2 context has been written and updated by hand over time and some of the ordering and formatting was not following a strict pattern. This attempts to clean it up to be easier to read. The format here is somewhat arbitrary, and other formats are possible, but this seems easy to work with. This organization was done by hand.
(Note this includes commits from #1510 due to github limitations and will be rebased if/when that is merged.)(Branch was rebased.)