DID WG Topic Call on Issue Processing Working Session — Minutes
Date: 2021-02-02
See also the Agenda and the IRC Log
Attendees
Present: Orie Steele, Justin Richer, Shigeya Suzuki, Adrian Gropper, Markus Sabadello, Ted Thibodeau Jr., Brent Zundel, Drummond Reed, Manu Sporny
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Adrian Gropper, Manu Sporny
Content:
Brent Zundel: the purpose of the meeting today is PRs
Manu Sporny: https://github.com/w3c/did-core/pulls
Manu Sporny: I’ve got a question about feature at risk for dag-cbor which I think we can close - any objection? - we will mark the CBOR section at risk separately.
… I will close that
… we need more input on deactivated flag
… trying to see if deactivated is a testable feature - I proposed some text - but lame - Daniel suggested that the property must be populated with a boolean - IF the did method has deactivated
Manu Sporny: proposed text : This property MUST be populated by a boolean value that is expected to be true if the DID has been deactivated, and false if the DID is still active.
Markus Sabadello: The essence of this PR is about changing deactivated from an error code - how to formulate it seems like a technicality - agree with manu’s text
Justin Richer: agree with the text in general - i disagree on what a normative statement means - I do not conclude that the presence of a normative statement needs to have a test - without deep insight we will not know if it’s lying
Brent Zundel: if this is related to the testing strategy about other normative statement?
Justin Richer: +1 for testing return values on the interface
Manu Sporny: not related to that - the only other statements we have are related to what a DID method specification needs to do - don’t believe we have statements about what a method should do - agree with Justin - all we can really test is that it’s a boolean value
… we should not pull in the further implication of that segment - this is new territory and don’t need t test it - if no objections to language - I will put it in
Justin Richer: not a huge fan of “is expected” just say “is”
Manu Sporny: is fine with “is” if no objections
Brent Zundel: no objections heard
Manu Sporny: Revised text: This property MUST be populated by a boolean value that is true if the DID has been deactivated, and false if the DID is still active.
Manu Sporny: last call… moving on
Manu Sporny: https://github.com/w3c/did-core/pull/586
Manu Sporny: Jonathan wanted the deterministic language back in the CBOR section, probably a duplicate of what already happened - any objections to close?
Justin Richer: encourage the chairs to do a sanity check in case there’s a difference
Manu Sporny: already done and asked jonathan
Justin Richer: OK
Manu Sporny: https://github.com/w3c/did-core/pull/587
Manu Sporny: https://github.com/w3c/did-core/pull/591
Manu Sporny: https://github.com/w3c/did-core/pull/592
Manu Sporny: next is DID resolution section: - will screen share
… trying to make it more clearly testable - disagreement on how - DID IDL ivan did not like because of browser implication - point taken to avoid external issues
… tried to simplify the abstract functions - but that was not just editorial so I made another PR - what about TypeScript - so I changed to that - still objections from justin and markus so a third PR…
… sharing screen with latest one… the front matter is supposed to be the same - from today’s DID Core text it’s not clear if it’s an array or a map, when you read it it sounds like it’s an ordered set. The other concern is that we talk about a DID document must be conforming - meaning
… that it follows the rules and it sounds like it’s the same as a stream -
… the abstract thing provides a return value and then we try to figure out what it is and might be conforming… I put both resolve and resolve representation back - it’s a map (not an ordered set)
… I did the same thing for the dereferencing section … so I think everything is back to the way it wa modulo pending editorial changes
… the other change is a move from kebab to camCase -
… and then the whole equivalentID makes me really sad wish Daniel B was here
Orie Steele: See https://w3c.github.io/did-core/#dfn-binding
Drummond Reed: +1 to referring to the Typescript example as a “binding”
Markus Sabadello: we should keep the distinction because resolve and resolve representation — did the - you also changed webIDL so good - wondering if we can call resolution a binding - I like the camelcase -
… it’s ok to say the output is a map - overall good
Justin Richer: the return value of resolve was going to be an INFRA map - resolve representation is different - glad to see the new version restores that
… the other bit, I’m with markus - don’t know that I’m in favor of returning just a single value - presumes a bit about how I’m returning things as a map - it presumes that the map is more difficult to read when you’re hiding the val in classes - it’s unnecessary - doesn’t change the testability - it’s ultimately an implementation option
… agree with markus and we should do more examples than TypeScript - don’t agree with putting them in the abstract function
Orie Steele: justin_r are we agreed to define the abstract functions completely in INFRA?
Manu Sporny: i’m hearing close 587 and 591 and keep working on 592 - any objections?
Markus Sabadello: I like Justin’s idea of having the examples in TypeScript example
Manu Sporny: to address justin and markus, change these values back to something that would work with a spread operator - is this an ordered set? was it intended to never be anything else?
Orie Steele: I continue to find these very confusing - they both are meant to be INFRA map - the DID stream different from DID - what’s the difference between is answered by concrete types
Justin Richer: +1 to concrete types - apologies for missing that - to answer manu’s question, not intended to be an ordered set - the order of the possible values is significant - you alway get back resolution - you sometimes get a did document but if error the others will be empty - reasonable to sy it looks like a map, a class, or an ordered set
… the goal of returning multiple values is not to presume a specific structure - I know most languages have only one return value but this is not a language - the flexibility was intended - the latter two should be nullable
Orie Steele: make it an infra map, not an infra set.
Orie Steele: make it clear
Justin Richer: +1 to the HTTP example
Orie Steele: to the best of my knowledge headers are always there, even if they are empty?
Justin Richer: Orie: it’s not a single data structure, it’s three values in parallel with each other; that’s why two are metadata
Markus Sabadello: you can argue either way - if we specifically it’s an INFRA map - if you implement as HTTP interface some could be in the body and others in the header -
Justin Richer: Orie: depends on your implementation
Orie Steele: sounds like cancer
Markus Sabadello: these are different things that you get back - if you implement in JavaScript but on the abstract level it’s not the perfect way to think about it - leave it up to the binding
Manu Sporny: trying to formulate all that - got it - new to me - I understand the intent - I can change these back - keep the order - keep it abstract
… in the TypeScript stuff we will show a map with {} - so they can see how to map into a concrete implementation - then we can hopefully write a test - any objection?
Justin Richer: +1 I think that captures it
Markus Sabadello: works for me - small comments about renaming metdata
Manu Sporny: yes, some was due to long names … there’s one last thing that concerns me … maps re still in the abstract
… is testable because there’s a concrete thing to test. But did document and did document stream have no distinction - can fix by stating that it is an INFRA map that conforms - but how do we test if it’s not tied to a serialization
Justin Richer: the testability .. the DID document is absolutely not a serialized implementation -
Manu Sporny: can’t test INFRA maps when the document has a representation we can test that - but when we say things are not realized can’t be tested - e.G. content type we can check bu
Justin Richer: what can’t you test the map that contains something
Manu Sporny: what was the intent?
Justin Richer: it is a parsed abstract data model
Manu Sporny: this s like UTF code points not bytes
Orie Steele: can we get some q management
Justin Richer: going to section 4 which states: A DID document is a map of properties - this is post parser - In order to test against a live representation… It was very clearly requested that we separate the return of an abstracted document vs. the serialized version
… I actually agree but the WG strongly dod not agree
… one other bit: syntax point putting the parentheses on function name is misleading
Markus Sabadello: I was also bit surprised to hear that the DID document is always in one of the representations - in some places it is the abstract map in other places -
… the idea of the two functions was to support both - did resolution is not one single protocol - that should be clear - needs to be clarified -
Orie Steele: realized what justin and markus - then there’s a separate set of tests for a concrete implementation - tests are of concrete implementation but implementers may have a hard time - I don’t find the ADM as helpful for testing - there should be very testable language about JSON JSON-LD -
… I have no idea how you would test the ADM -
Justin Richer: the people who wanted it aren’t on the call
Manu Sporny: Markus, Justin, me, Orie dont want this. Why don’t we throw it out - the WG made us do this but who remains that wants us to do this? who are the individuals?
… what is the compelling reason to keep this in the spec?
… can we just remove this from the spec?
Justin Richer: -1 to overturning the WG decisions at the last minute because we don’t like it
Orie Steele: some of the people who wanted it are not working group members.
Markus Sabadello: the origin of the ADM was that some people wanted losses conversion if that still works
Manu Sporny: not proposing removing the ADM , just this one thing - this interface -
Orie Steele: yes
Markus Sabadello: we need to test the resolver presentation function -
Manu Sporny: let’s not attach normative statement to abstract things
Orie Steele: +1 to manu’s suggestion…. not sure how to test ADM
Justin Richer: testability is based on a very limited view - I do not think we should throw this out