Make "id" optional for services and public keys. #66
Conversation
index.html
Outdated
| <code>type</code>, and <code>serviceEndpoint</code> properties, and | ||
| MAY include additional properties. | ||
| Each service endpoint MAY include an <code>id</code> property. | ||
| The array of service endpoints MUST NOT contain duplicate entries |
There was a problem hiding this comment.
Again, should processors throw errors if they find duplicate entries? We should probably define a conformance class here for a DID Document processor and restate this as "A DID Document Processor MUST throw an error if there are duplicate entries with the same id." ... or something to that effect.
There was a problem hiding this comment.
Yes, I'd say throw an error in this case, as above. Regarding a "DID Document Processor" conformance class, do you want to do that here in this PR, or would that first have to be introduced/defined elsewhere?
There was a problem hiding this comment.
Regarding a "DID Document Processor" conformance class, do you want to do that here in this PR, or would that first have to be introduced/defined elsewhere?
Ideally, we'd define a DID Document Processor conformance class first, merge that in, then fix this one and merge it in.
Alternatively, and I think this would be faster, just raise an issue stating that we need to define a DID Document Processor conformance class, fix this PR so it throws an error, we'll merge this, and get to the DID Document Processor conformance class later. Better to get this PR merged than have it hang out there for too long.
|
|
||
| <li> | ||
| Each service endpoint MUST include <code>type</code> and | ||
| <code>serviceEndpoint</code> properties, and MAY include additional |
There was a problem hiding this comment.
We need to go through the spec and talk about property-value pairs. properties may be confusing to readers... because they're typically the "key" part of a "key-value" pair.
There was a problem hiding this comment.
It's an RDF term, right? And it's used in many places throughout the spec. So how about we don't address it in this specific PR, but instead raise a new (editorial) issue to see if we can find a better term.
There was a problem hiding this comment.
Not RDF... that's predicate-object (which will just confuse everyone, so we shouldn't use it). "key-value" is concerning because of the prevalence of "public keys" in the spec. We try to define things using JSON-ish terminology, but we should probably avoid the phrase "key-value" and prefer "property-value" to refer to the data model concept of an associative array... but your suggestion works for me, let's deal with it in another PR.
Co-Authored-By: Manu Sporny <msporny@digitalbazaar.com>
Co-Authored-By: Manu Sporny <msporny@digitalbazaar.com>
|
The JSON terminology is "member": "value". |
Co-Authored-By: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-Authored-By: Manu Sporny <msporny@digitalbazaar.com>
|
@selfissued wrote:
Ugh, you're right... I was thinking of Javascript's object properties -- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/getOwnPropertyNames Wonder why JSON deviated from that language... |
To address feedback at #66 (comment).
|
If this is merged, I think it also makes #46 obsolete (see discussion there). |
|
Discussed during telecon, multiple positive reviews, suggestions applied, no objections, merging. |
* Make "id" optional for services and public keys. * Change MAY to SHOULD for public keys. * Change MAY to SHOULD for service endpoints. * Say "multiple" instead of "duplicate" entries. * Apply suggestion from @msporny. * Add comment about producing an error. * Address feedback at w3c/did-core#66 (comment).
Fixes #47 (see discussion there).
Preview | Diff