23:09:27 <RRSAgent> RRSAgent has joined #did-topic
23:09:27 <RRSAgent> logging to https://www.w3.org/2021/02/02-did-topic-irc
23:09:43 <Orie> present+
23:09:45 <justin_r> present+
23:09:47 <shigeya> present+
23:09:48 <manu> brent: the purpose of the meeting today is PRs
23:09:53 <agropper> present+
23:09:53 <manu> https://github.com/w3c/did-core/pulls
23:09:53 <markus_sabadello> present+
23:09:55 <TallTed> present+
23:09:56 <manu> scribe: agropper
23:09:58 <brent> present+
23:10:00 <manu> manu: I'v 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.
23:10:02 <markus_sabadello> q+
23:10:06 <manu> manu: I will close that
23:10:09 <justin_r> q+
23:10:12 <manu> manu: we need more input on deactivated flag
23:10:21 <manu> manu: 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
23:10:27 <brent> q+ to ask about what the testing strategy is for other DID Method normative statements
23:10:27 <manu> 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.
23:10:41 <brent> ack markus_sabadello
23:11:33 <agropper> markus: 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
23:11:44 <brent> ack justin_r
23:12:56 <agropper> justin: 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
23:12:56 <manu> q+ to note that all we can test is the return value.
23:12:59 <brent> ack brent
23:12:59 <Zakim> brent, you wanted to ask about what the testing strategy is for other DID Method normative statements
23:13:30 <brent> ack manu
23:13:30 <Zakim> manu, you wanted to note that all we can test is the return value.
23:13:32 <agropper> brent: if this is related to the testing strategy about other normative statement?
23:13:34 <manu> q+ to respond to brent
23:14:35 <justin_r> +1 for testing return values on the interface
23:14:51 <agropper> manu: 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
23:15:17 <brent> ack manu
23:15:17 <Zakim> manu, you wanted to respond to brent
23:15:54 <justin_r> q+
23:16:00 <brent> ack justin_r
23:16:00 <agropper> ... 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
23:16:22 <agropper> justin: not a huge fan of "is expected" just say "is"
23:16:54 <agropper> manu: is fine with "is" if no objections
23:17:13 <agropper> brent: no objections heard
23:17:18 <manu> 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.
23:17:58 <agropper> manu: last call... moving on
23:18:09 <manu> https://github.com/w3c/did-core/pull/586
23:18:57 <justin_r> q+
23:19:03 <brent> ack justin_r
23:19:06 <agropper> ... Jonathan wanted the deterministic language back in the CBOR section, probably a duplicate of what already happened - any objections to close?
23:19:31 <agropper> justin: encourage the chairs to do a sanity check in case there's a difference
23:19:42 <agropper> manu: already done and asked jonathan
23:19:47 <agropper> justin: OK
23:20:23 <manu> https://github.com/w3c/did-core/pull/587
23:20:32 <manu> https://github.com/w3c/did-core/pull/591
23:20:34 <manu> https://github.com/w3c/did-core/pull/592
23:20:35 <agropper> manu: next is DID resolution section: - will screen share
23:21:47 <agropper> manu: 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
23:22:58 <agropper> ... 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...
23:23:17 <markus_sabadello> q+
23:23:58 <justin_r> q+
23:24:41 <agropper> ... 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
23:25:21 <agropper> ... that it follows the rules and it sounds like it's the same as a stream -
23:26:25 <justin_r> q+ to speak out against the return value
23:26:29 <agropper> ... 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)
23:27:11 <agropper> ... I did the same thing for the dereferencing section ... so I think everything is back to the way it wa modulo pending editorial changes
23:27:41 <agropper> ... the other change is a move from kebab to camCase -
23:28:04 <brent> ack markus_sabadello
23:28:11 <agropper> ... and then the whole equivalentID makes me really sad wish Daniel B was here
23:28:55 <drummond> drummond has joined #did-topic
23:29:00 <drummond> present+
23:29:26 <Orie> See https://w3c.github.io/did-core/#dfn-binding
23:29:31 <drummond> +1 to referring to the Typescript example as a "binding"
23:29:36 <brent> rrsagent, who is here?
23:29:36 <RRSAgent> I'm logging.  Sorry, nothing found for 'who is here'
23:29:48 <brent> zakim, who is here?
23:29:48 <Zakim> Present: Orie, justin_r, shigeya, agropper, markus_sabadello, TallTed, brent, drummond
23:29:50 <Zakim> On IRC I see drummond, RRSAgent, Zakim, Orie, agropper, brent, burn, markus_sabadello, justin_r, TallTed, jonathan_holt, shigeya, ChristopherA, manu, dlongley, rhiaro
23:30:03 <agropper> markus: 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 -
23:30:16 <brent> present+ manu
23:30:26 <agropper> ... it's ok to say the output is a map - overall good
23:30:27 <brent> ack justin_r
23:30:27 <Zakim> justin_r, you wanted to speak out against the return value
23:31:34 <agropper> justin: the return value of resolve was going to be an INFRA map - resolve representation is different - glad to see the new version restores that
23:33:23 <agropper> ... 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
23:34:06 <agropper> ... agree with markus and we should do more examples than TypeScript - don't agree with putting them in the abstract function
23:34:10 <manu> q+ to rpopose changes
23:34:12 <Orie> justin_r are we agreed to define the absract functions completely in INFRA?
23:34:15 <markus_sabadello> q+
23:34:15 <brent> ack manu
23:34:16 <Zakim> manu, you wanted to rpopose changes
23:34:54 <agropper> manu: i'm hearing close 587 and 591 and keep working on 592 - any objections?
23:35:03 <brent> ack markus_sabadello
23:35:07 <manu> q+ to next set of proposals
23:35:26 <agropper> markus: I like Justin's idea of having the examples in TypeScript example
23:35:31 <brent> ack manu
23:35:31 <Zakim> manu, you wanted to next set of proposals
23:35:59 <Orie> q+ to assk about infra?
23:36:04 <justin_r> q+
23:36:09 <justin_r> q+ to answer manu
23:36:24 <agropper> manu: 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?
23:36:25 <brent> acl Orie
23:36:28 <brent> ack Orie
23:36:28 <Zakim> Orie, you wanted to assk about infra?
23:37:25 <brent> ack justin_r
23:37:25 <Zakim> justin_r, you wanted to answer manu
23:37:29 <agropper> orie: 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
23:37:37 <markus_sabadello> q+
23:39:16 <agropper> justin: +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
23:40:30 <agropper> ... 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
23:40:32 <manu> q+
23:40:34 <brent> ack markus_sabadello
23:40:40 <Orie> make it an infra map, not an infra set.
23:40:42 <Orie> make it clear
23:41:24 <justin_r> +1 to the HTTP example
23:41:48 <Orie> to the best of my knowledge headers are always there, even if they are empty?
23:41:50 <justin_r> Orie: it's not a single data structure, it's three values in parallel with each other; that's why two are metadata
23:41:51 <agropper> markus: you can argue either way - if we specifically it's a iNFRA map - if you implement as HTTP interface some could be in the body and others in the header -
23:42:02 <justin_r> Orie: depends on your implementation
23:42:08 <Orie> sounds like cancer
23:42:53 <agropper> ... 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
23:42:58 <brent> ack manu
23:43:45 <agropper> manu: 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
23:44:46 <markus_sabadello> q+
23:44:51 <brent> ack markus_sabadello
23:44:52 <agropper> ... 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?
23:44:54 <justin_r> +1 I think that captures it
23:45:06 <justin_r> q+ to discuss a nit on referencing the functions in the text and other stuff
23:45:13 <agropper> markus: works for me - small comments about renaming metdata
23:45:55 <agropper> manu: yes, some was due to long names ... there's one last thing that concerns me ... maps re still in the abstract
23:46:23 <markus_sabadello> q+
23:47:13 <agropper> ... 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
23:47:15 <justin_r> q+ to talk testability
23:47:20 <brent> ack justin_r
23:47:20 <Zakim> justin_r, you wanted to discuss a nit on referencing the functions in the text and other stuff and to talk testability
23:47:49 <agropper> justin: the testability .. the DID document is absolutely not a serialized implementation -
23:47:58 <agropper> manu: can't test INFRA maps
23:48:23 <Orie> q+ to note the existing resolution tests
23:49:00 <agropper> .. 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
23:49:18 <agropper> justin: what can't you test the map that contains something
23:49:25 <agropper> manu: what was the intent?
23:49:38 <agropper> justin: it is a parsed abstract data model
23:49:49 <Orie> q?
23:49:58 <agropper> manu: this s like UTF code points not bytes
23:51:05 <Orie> can we get some q management
23:51:30 <agropper> justin: 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
23:51:54 <agropper> ... I actually agree but the WG strongly dod not agree
23:51:55 <manu> q+
23:52:32 <brent> ack markus_sabadello
23:52:34 <agropper> justin: one other bit: syntax point putting thparentheses on function name is misleading
23:53:28 <agropper> markus: 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 -
23:54:26 <agropper> ... 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 -
23:54:28 <brent> ack Orie
23:54:28 <Zakim> Orie, you wanted to note the existing resolution tests
23:54:59 <markus_sabadello> q+
23:55:27 <manu> q?
23:56:36 <agropper> orie: 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 -
23:56:51 <agropper> ... I have no idea how you would test the ADM -
23:56:56 <brent> ack manu
23:57:20 <justin_r> the people who wanted it aren't on the call
23:57:45 <Orie> q+
23:57:52 <agropper> manu: 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?
23:58:01 <justin_r> -1 to overturning the WG decisions at the last minute because we don't like it
23:58:11 <Orie> some of the people who wanted it are not working group members.
23:58:22 <agropper> ... what is the compelling reason to keep this in the spec?
23:58:38 <agropper> ... can we just remove this from the spec?
23:58:41 <brent> ack markus_sabadello
23:58:44 <justin_r> q
23:59:11 <agropper> markus: the origin of the ADM was that some people wanted losses conversion if that still works
23:59:31 <Orie> q-
23:59:36 <agropper> manu: not proposing removing the ADM , just this one thing - this interface -
23:59:48 <Orie> yes
00:00:00 <agropper> markus: we need to test the resolver presentation function -
00:00:07 <justin_r> q+
00:00:13 <brent> ack justin_r
00:00:21 <agropper> manu: let's not attach normative statement to abstract things
00:00:22 <Orie> +1 to manu's suggestion.... not sure how to test ADM
00:01:03 <agropper> justin: testability is based on a very limited view - I do not think we should throw this out
00:02:08 <brent> rrsagent, draft minutes
00:02:08 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/02-did-topic-minutes.html brent
00:02:17 <brent> rrsagent, make logs public
00:02:35 <brent> zakim, this is did
00:02:35 <Zakim> got it, brent
00:02:40 <brent> Chair: brent
00:03:05 <brent> Meeting: DID WG Topic Call
00:03:54 <brent> zakim, end the meeting
00:03:54 <Zakim> As of this point the attendees have been Orie, justin_r, shigeya, agropper, markus_sabadello, TallTed, brent, drummond, manu
00:03:56 <Zakim> RRSAgent, please draft minutes
00:03:56 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/02-did-topic-minutes.html Zakim
00:03:59 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
00:04:03 <Zakim> Zakim has left #did-topic
00:04:11 <brent> rrsagent, please excuse us
00:04:11 <RRSAgent> I see no action items