22:58:48 <RRSAgent> RRSAgent has joined #did-topic
22:58:48 <RRSAgent> logging to https://www.w3.org/2021/02/16-did-topic-irc
22:59:00 <manu> Topic: DID Special Topic Call
22:59:05 <manu> rrsagent, make logs public
22:59:12 <manu> rrsagent, draft minutes
22:59:12 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/16-did-topic-minutes.html manu
22:59:49 <manu> s/Topic:/Meeting:/
22:59:51 <manu> rrsagent, draft minutes
22:59:51 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/16-did-topic-minutes.html manu
23:01:45 <shigeya> present+
23:01:56 <brent_> brent_ has joined #did-topic
23:02:11 <brent> present+
23:02:15 <markus_sabadello> markus_sabadello has joined #did-topic
23:02:16 <TallTed> present+
23:02:19 <manu> present+
23:02:21 <markus_sabadello> present+
23:03:38 <kdenhartog> kdenhartog has joined #did-topic
23:03:47 <kdenhartog> present+
23:04:00 <kdenhartog> scribe+
23:04:06 <manu> q+
23:04:23 <kdenhartog> brent: purpose of meeting is to look at PRs and find consensus on them in prep for CR
23:04:30 <kdenhartog> ... turning things over to Queue
23:04:37 <brent> ack manu
23:04:46 <kdenhartog> manu: Sent email out with statements to help get clarity around
23:04:56 <kdenhartog> ... looking at the PRs that have disagreement on
23:05:09 <kdenhartog> ... going to copy paste them as we go
23:05:16 <kdenhartog> ... one has to do with ADM
23:05:26 <kdenhartog> ... and what it's intended to test
23:05:39 <kdenhartog> ... the next is about testability of resolution section and how pedantic we want to me
23:05:50 <kdenhartog> ... third is about representation specific properties
23:06:03 <kdenhartog> ... how are we planning to deal with these
23:06:24 <agropper> agropper has joined #did-topic
23:06:34 <kdenhartog> ... is there anyone on call that has a proposal that may make it easier for us to resolve them
23:06:36 <agropper> present+
23:06:46 <kdenhartog> q+
23:06:55 <brent> ack kdenhartog
23:07:04 <manu> kdenhartog: I think those are higher priority, I'd like to add on DID COntext issue -- small one, want some resolution.
23:07:54 <kdenhartog> manu: let's address ADM model first because it has most prolific effect. Any objections?
23:08:05 <manu> 1. The ADM MUST ONLY be used to represent a DID Document.
23:08:06 <manu> 2. The ADM can be used to represent any data structure in
23:08:06 <manu>    the DID Core specification, e.g., a resolution metadata
23:08:06 <manu>    structure, or a verification method.
23:08:49 <markus_sabadello> q+
23:09:07 <kdenhartog> manu: These are two statements we have that. I think these are the two fundamental section that should be discussed
23:09:14 <brent> ack markus_sabadello
23:09:45 <kdenhartog> markus_sabadello: I think this is related to the second topic as well. I expressed my opinion on that previously. I don't think we should expand past the DID Document for ADM
23:09:57 <drummond> drummond has joined #did-topic
23:10:17 <kdenhartog> ... I will also note that there's been a few PRs that have already moved us in that direction. I don't think they should have been merged
23:10:36 <manu> q+ to note that we have a general abstract data model, so this is easy to do -- general data models usually don't say "here's a general data model, now you can only use it for one thing."
23:10:39 <Orie> Orie has joined #did-topic
23:10:41 <kdenhartog> ... one was editorial and I don't think it was editorial. The second had an objection but was also merged
23:10:43 <Orie> present+
23:10:46 <brent> ack manu
23:10:46 <Zakim> manu, you wanted to note that we have a general abstract data model, so this is easy to do -- general data models usually don't say "here's a general data model, now you can only
23:10:49 <Zakim> ... use it for one thing."
23:11:03 <kdenhartog> manu: Anything that was merged that shouldn't have been merged should be reverted out
23:11:05 <markus_sabadello> https://github.com/w3c/did-core/pull/631 and https://github.com/w3c/did-core/pull/601 added language about expanding the data model that I think shouldn't been merged.
23:11:07 <wayne> wayne has joined #did-topic
23:11:36 <kdenhartog> ... I haven't seen any issues but we're moving quickly so may have missed something
23:11:59 <Orie> q+ to ask what is an abstract data model did document
23:12:17 <kdenhartog> ... I think theres a fundamental contention that the ADM was for only the DID Document and nothing else
23:13:13 <kdenhartog> ... normally when a programming language has a ADM it doesn't also place limitations on what that data model can be used for
23:13:49 <markus_sabadello> q+
23:14:11 <kdenhartog> ... it's strange to say that only the DID Document can be expressed in the ADM and I think it's overlimiting, doesn't buy us anything, and makes issue 2 (resolution testability) more complex
23:14:18 <brent> ack Orie
23:14:18 <Zakim> Orie, you wanted to ask what is an abstract data model did document
23:15:05 <kdenhartog> Orie: I think we've opened the world for what a DID Document can be beyond what has been imagined
23:15:22 <brent> rrsagent, who is here?
23:15:22 <RRSAgent> I'm logging.  Sorry, nothing found for 'who is here'
23:15:30 <brent> zakim, who is here?
23:15:30 <Zakim> Present: shigeya, brent, TallTed, manu, markus_sabadello, kdenhartog, agropper, Orie
23:15:32 <Zakim> On IRC I see wayne, Orie, drummond, agropper, kdenhartog, markus_sabadello, brent, RRSAgent, Zakim, shigeya, TallTed, ChristopherA, manu, dlongley, rhiaro
23:15:35 <dwaite> dwaite has joined #did-topic
23:15:36 <kdenhartog> ...Anything can be added to the DID Document as long as id property is present
23:16:16 <kdenhartog> ... I think it's uncorrect to assume the additional resolution data isn't also part of the DID Document
23:16:16 <brent> present+ drummond
23:16:23 <brent> present+ dwaite
23:16:52 <kdenhartog> ... it's poor engineering if we say that unknown properties can't be handled
23:17:08 <manu> q+ to note how this plays out for the Resolution metadata structure.
23:17:20 <kdenhartog> ... they can have anything else in it as long as the id, I think we need to agree on what a DID Document is first before we talk about ways to get them
23:17:27 <brent> ack markus_sabadello
23:18:26 <kdenhartog> markus_sabadello: I think you misunderstood me Orie. I didn't say it couldn't be anything and be extensible. I think that's fine. I think what you said actually supports my perspective a bit more and Manu is saying the ADM should apply to other structures that don't have an ID
23:18:37 <manu> q+ to note that we clearly call out "DID Document expressed using data model" in the rework.
23:19:20 <kdenhartog> ... I think it's a good thing to keep the DID Document as is and don't think we need to change that
23:19:22 <brent> ack manu
23:19:22 <Zakim> manu, you wanted to note how this plays out for the Resolution metadata structure. and to note that we clearly call out "DID Document expressed using data model" in the rework.
23:19:45 <kdenhartog> manu: to answer why do we need now question, it's been to assist with resolution section for testing
23:20:16 <kdenhartog> ... we want to make sure there's a clear line for going from the ADM to something testable other than for a few INFRA maps
23:20:21 <markus_sabadello> q+
23:20:36 <kdenhartog> ... it's fairly obvious that they should be converted to JSON, but without saying that it's not clear that's how that should be handled
23:21:12 <kdenhartog> ... We have these maps of did document metadata. How do we tell implementors how to handle those maps?
23:21:43 <kdenhartog> ... we can reference the resolution sections to make it easy to serialize the maps into JSON
23:21:51 <Orie> q+ to note that the resolution response is problematic.
23:22:32 <kdenhartog> ... if you have a map just go take a look at the JSON serialization rules. It didn't cut off any use cases we had before, but made it clear for implementors of how to go from ADM to a representation when we have these additional maps
23:22:53 <kdenhartog> ... if we don't want to do that then we're just going to end up repeating the same language
23:23:31 <kdenhartog> ... thats the why we need this. If we don't have that we need to find a different way to handle the testability
23:23:45 <kdenhartog> ... I'd like to run 2 proposals to see if we can move on
23:23:47 <manu> q+ to run proposals
23:24:04 <kdenhartog> brent: add your self to q to run the proposals
23:24:14 <brent> ack markus_sabadello
23:24:24 <kdenhartog> markus_sabadello: the section on metadata structure already has some examples
23:24:44 <kdenhartog> ... I think it would be much simpler to add a sentence to reference the INFRA spec
23:25:01 <manu> q+ to note that it's not jsut about metadata structure, what about a verification method, or a service?
23:25:03 <kdenhartog> ... I think this makes it testable without expanding the scope of the ADM at this point
23:25:09 <brent> ack Orie
23:25:09 <Zakim> Orie, you wanted to note that the resolution response is problematic.
23:25:16 <kdenhartog> Orie: I misinterpreted markus earlier
23:25:26 <kdenhartog> ... the issue here is the did resolution buckets
23:26:19 <drummond> q+ to ask about the scope of what we say in the spec about resolution
23:26:30 <manu> q- later
23:26:49 <markus_sabadello> q+
23:26:57 <manu> q- later
23:27:12 <brent> ack drummond
23:27:12 <Zakim> drummond, you wanted to ask about the scope of what we say in the spec about resolution
23:27:12 <kdenhartog> ... I agree this is a problem, one solution is to say there's only one way to return which is JSON, another is to add the additional objects to the ADM and say how to handle that
23:28:34 <kdenhartog> drummond: It seems to me that resolution data is out of scope and if that's true then should we be handling it?
23:28:36 <brent> ack markus_sabadello
23:28:43 <Orie> I think we migtht be better off kicking the meta data out of the spec, or handling in in all supported representations... its going to hurt to split the difference.
23:29:15 <kdenhartog> markus_sabadello: I understand orie's rationale that when you resolve a did then you get back the whole resolution object in JSON-ld or cbor
23:29:21 <manu> q+ to note -- never /always/
23:29:31 <kdenhartog> ... I think it's a mistake to think the whole resolution object is not a single object
23:29:50 <kdenhartog> ... we agreed that they are separate objects and the encoding/serialization may be different
23:30:23 <kdenhartog> ... you may get them in different ways so we should avoid the impression that they'll always be combined
23:31:09 <kdenhartog> ... we could use JSON as an example, but I think reusing the entire ADM goes to far and is misleading
23:31:15 <brent> ack manu
23:31:15 <Zakim> manu, you wanted to run proposals and to note that it's not jsut about metadata structure, what about a verification method, or a service? and to note -- never /always/
23:31:20 <kdenhartog> manu: Gonna run the proposals
23:31:56 <markus_sabadello> I think I would agree to expand the data model to parts of DID document, but not to metadata
23:32:04 <manu> PROPOSAL: The ADM MUST ONLY be used to represent a DID Document.
23:32:08 <kdenhartog> ... wanna note that this about specific aspects in the DID Doc such as Verification Method or service object
23:32:09 <manu> -1
23:32:15 <drummond> 0
23:32:22 <kdenhartog> 0
23:32:26 <TallTed> -0.5
23:32:27 <Orie> +1
23:32:31 <markus_sabadello> +0.5 (okay with using it for parts of DID documents, but not for non-DID document structures)
23:32:34 <shigeya> 0
23:32:43 <brent> 0
23:33:02 <manu> PROPOSAL: The ADM can be used to represent any data structure in the DID Core specification, e.g., a resolution metadata structure, or a verification method.
23:33:02 <manu> +1
23:33:10 <Orie> +1
23:33:17 <drummond> 0
23:33:20 <kdenhartog> +.5
23:33:21 <markus_sabadello> -1
23:33:28 <shigeya> +0.5
23:33:28 <brent> 0
23:33:38 <TallTed> +1
23:34:28 <markus_sabadello> PROPOSAL: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method)
23:34:53 <manu> -0.5 (I think this would be better, but doesn't address the issue)
23:35:04 <drummond> +0.5
23:35:08 <markus_sabadello> +1
23:35:24 <kdenhartog> +1
23:35:24 <TallTed> -0.5
23:35:53 <manu> q+
23:36:21 <drummond> +1 to Kyle's suggestion
23:36:31 <shigeya> +1 to Kyle's suggestion
23:36:37 <brent> ack manu
23:37:33 <Orie> we should remove all normative statements associated with resolution response that are not about the did document.
23:38:02 <drummond> +1 to Orie's point
23:38:11 <kdenhartog> manu: I would like to specify that the ADM can be specified for DID Document or sub structures. I think Kyle's proposal is ugly but if people will support it then we're going to have to find a way to make it work
23:38:15 <drummond> q+
23:38:21 <brent> ack drummond
23:38:32 <manu> q+
23:38:36 <markus_sabadello> q+
23:38:47 <kdenhartog> drummond: It seems consistent with we're only specifying the contract
23:38:52 <brent> ack manu
23:39:33 <kdenhartog> manu: My concern is that while that's what we're saying that's not what the spec text is actually doing. We're specifying something beyond abstract
23:39:45 <drummond> q+
23:40:20 <brent> ack markus_sabadello
23:40:22 <drummond> I'm in favor of revising the spec text to make sure that it is consistent with keeping it at the level of a resolution contract
23:40:37 <kdenhartog> markus_sabadello: In theory this would work by making this testable at least
23:41:02 <kdenhartog> ... it's sufficient to say that it can be done in some way without stating how to do it in greater detail
23:41:13 <brent> ack drummond
23:41:20 <kdenhartog> +1 better not to over specify now and leave much of that for did resolution work
23:41:54 <kdenhartog> drummond: If there's normative statments that demand at a lower level than what's testable then we need change those statements
23:42:18 <kdenhartog> ... What ever level we're after we need to update the language to make it work
23:42:40 <kdenhartog> +1
23:43:08 <kdenhartog> brent: is there anyone who'd like to modify changes to the proposal?
23:43:16 <manu> PROPOSAL: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method). For DID Resolution data structures, INFRA will be referenced normatively, as well as the JSON serialization rules for INFRA, to note that the data structure must be able to be serialized using INFRA->JSON rules.
23:43:22 <Orie> +1
23:43:25 <kdenhartog> +1
23:43:32 <drummond> +1
23:43:33 <markus_sabadello> +1
23:43:37 <shigeya> +1
23:43:38 <brent> +1
23:43:42 <manu> +0.5 (weird and duplicative text in the spec)
23:44:04 <TallTed> +0.5 is viable ... but people are definitely gonna try to wedge apples into that bag for oranges
23:44:30 <brent> RESOLVED: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method). For DID Resolution data structures, INFRA will be referenced normatively, as well as the JSON serialization rules for INFRA, to note that the data structure must be able to be serialized using INFRA->JSON rules.
23:44:54 <manu> q+
23:44:55 <kdenhartog> brent: Where do we go from here?
23:45:00 <brent> ack manu
23:45:23 <kdenhartog> manu: I think that resolves issue 1 and 2, my hope that the next proposal will pass
23:46:22 <kdenhartog> ... if you -1 this proposal you're saying even if it's possible (it now is after last resolution) then you're saying that you don't want it
23:46:47 <kdenhartog> brent: would it be fair to say if the caveat it's not then should we add language to support that?
23:46:55 <kdenhartog> manu: if it's not possible we need to talk about it
23:47:09 <kdenhartog> drummond: if something falls under human testable category what should we do?
23:47:19 <kdenhartog> manu: we should talk about it if it has to be human testable
23:47:39 <manu> PROPOSAL: If possible, and in order to increase interoperability, we should ensure that every normative MUST statement is machine-testable in the DID Resolution section. If it turns out to not be possible then further discussion will be necessary.
23:47:42 <manu> +1
23:47:42 <drummond> +1
23:47:44 <kdenhartog> +1
23:47:46 <TallTed> +1
23:47:47 <Orie> +1
23:47:47 <brent> +1
23:47:48 <shigeya> +1
23:47:49 <markus_sabadello> +1
23:48:01 <agropper> +1
23:48:07 <brent> RESOLVED: If possible, and in order to increase interoperability, we should ensure that every normative MUST statement is machine-testable in the DID Resolution section. If it turns out to not be possible then further discussion will be necessary.
23:48:27 <kdenhartog> manu: next one has to do with representation specific entries
23:49:00 <kdenhartog> ... there's thing that are specific to representations like @context which could be argued is specific to json-ld, yaml versions for yaml, etc
23:49:19 <kdenhartog> ... we've said these representation specific things have to be kept in the ADM
23:49:37 <kdenhartog> ... this has lead to some disagreement
23:49:47 <manu> 1. The representation-specific entries go into the DID
23:49:47 <manu>    Document data model.
23:49:47 <manu> 2. The representation-specific entries go into some other
23:49:47 <manu>    data model.
23:49:48 <manu> 3. The representation-specific entries go into the
23:49:49 <manu>    DID Document data model AND some representation-
23:49:50 <manu>    specific map.
23:50:04 <kdenhartog> ... for example how to go from an ADM without @context and returning JSON-LD, where does that context value come from?
23:50:07 <markus_sabadello> q+
23:52:19 <brent> ack markus_sabadello
23:52:19 <kdenhartog> ... these are the 3 things we could talk about let's go to the queue
23:52:40 <kdenhartog> markus_sabadello: I've felt uncomfortable including representation specific properties in the ADM
23:52:47 <kdenhartog> ... seems like a violation of layers
23:53:11 <kdenhartog> ... could produce issues later on when new presentations are defined
23:53:45 <TallTed> Can we put all the core stuff into Registries, with their @context alongside as with any non-core stuff, such that the only things that would get a magic @context would be unRegistered whose authors are clearly warned that Here Be Dragons if they fail to register their special thing? So, no big @context for Core, just lots of little ones for each and every...
23:54:04 <kdenhartog> ... I'm not sure what the solution. Out of the 3 options listed I like option 3 best
23:54:20 <drummond> q+
23:54:23 <Orie> q+ to note the issues with each
23:54:31 <brent> ack drummond
23:54:34 <kdenhartog> ... that with clarity around what the production rules are doing could help
23:55:09 <manu> q+ to run a proposal.
23:55:11 <kdenhartog> drummond: we've discussed for quite awhile. Is there a proposal that we can be specific about?
23:55:18 <Orie> q-
23:55:21 <kdenhartog> ... I'm asking for clarity on that is all
23:55:21 <markus_sabadello> Controversial diagram: https://github.com/w3c/did-core/pull/596
23:55:25 <brent> ack manu
23:55:25 <Zakim> manu, you wanted to run a proposal.
23:56:26 <kdenhartog> manu: let's try option 3, but sounds like Markus wanted an OR rather than AND. Let me see if I can rework that
23:56:32 <kdenhartog> ... let's give this a shot
23:57:32 <drummond> q+
23:57:52 <Orie> q+ to talk about production
23:57:59 <kdenhartog> ... I think this is going to be used to argue that json-ld shouldn't include the @context property
23:58:15 <kdenhartog> ... let's here from Markus and Orie to see how we might handle it
23:58:17 <markus_sabadello> +1
23:58:17 <brent> ack drummond
23:58:46 <kdenhartog> drummond: We passed a resolution several calls ago to say representation specific entries must follow production rules
23:58:52 <brent> ack Orie
23:58:52 <Zakim> Orie, you wanted to talk about production
23:59:35 <kdenhartog> Orie: We've been over this and resolved that and I'll be -1 on going back on that. Markus and Justin have brought up a good point about what happens when you start with empty ADM. How should production handle this?
00:00:20 <kdenhartog> ... either we add this to ADM which feels wrong, or we have a production rule which applies specifically to the representation when combined with the ADM
00:00:24 <shigeya> I'm wondering whether ADM is read only or not...
00:00:31 <kdenhartog> brent: we're out of time
00:00:37 <manu> It is not read-only.
00:00:49 <TallTed> also, what does production mean/require when you've consumed 1000s of DID documents with *lots* of individuated special properties? Do you have to output 100s of empty properties, or is it OK to leave out empty properties (we often say it's not)>
00:00:58 <kdenhartog> ... those who are still wanting to work on this please discuss offline
00:01:02 <shigeya> Then, how we can guarantee these two are in sync... is a question
00:01:58 <manu> rrsagent, draft minutes
00:01:58 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/16-did-topic-minutes.html manu
00:02:04 <brent> zakim, who is here?
00:02:04 <Zakim> Present: shigeya, brent, TallTed, manu, markus_sabadello, kdenhartog, agropper, Orie, drummond, dwaite, .5
00:02:06 <Zakim> On IRC I see dwaite, wayne, Orie, drummond, agropper, kdenhartog, markus_sabadello, brent, RRSAgent, Zakim, shigeya, TallTed, ChristopherA, manu, dlongley, rhiaro
00:02:19 <brent> present- .5
00:02:21 <brent> zakim, who is here?
00:02:21 <Zakim> Present: shigeya, brent, TallTed, manu, markus_sabadello, kdenhartog, agropper, Orie, drummond, dwaite
00:02:24 <Zakim> On IRC I see dwaite, wayne, Orie, drummond, agropper, kdenhartog, markus_sabadello, brent, RRSAgent, Zakim, shigeya, TallTed, ChristopherA, manu, dlongley, rhiaro
00:02:50 <brent> rrsagent, make logs public
00:02:57 <dwaite> I had the benefit of watching things unfold
00:03:03 <brent> zakim, end the meeting
00:03:03 <Zakim> As of this point the attendees have been shigeya, brent, TallTed, manu, markus_sabadello, kdenhartog, agropper, Orie, drummond, dwaite, .5
00:03:05 <Zakim> RRSAgent, please draft minutes
00:03:05 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/16-did-topic-minutes.html Zakim
00:03:08 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
00:03:14 <Zakim> Zakim has left #did-topic
00:03:16 <dwaite> and I guess of manu being so incorrect that markus was incorrect too by proxy
00:03:21 <brent> rrsagent, bye
00:03:21 <RRSAgent> I see no action items
00:03:22 <dwaite> (if I picked that up right)