16:57:19 RRSAgent has joined #did-topic 16:57:19 logging to https://www.w3.org/2021/02/11-did-topic-irc 16:57:21 RRSAgent, make logs Public 16:57:22 please title this meeting ("meeting: ..."), ivan 16:57:25 Meeting: DID WG Topic Call on Issue Processing Working Session 16:57:25 Chair: brent 16:57:25 Date: 2021-02-11 16:57:25 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Feb/0006.html 17:01:01 markus_sabadello has joined #did-topic 17:01:03 present+ 17:01:08 present+ 17:01:13 present+ brent 17:01:18 present+ shigeya 17:01:23 present+ manu 17:01:47 brent has joined #did-topic 17:01:55 present+ 17:02:04 scribe? 17:02:12 zakim, pick a victim 17:02:12 Not knowing who is chairing or who scribed recently, I propose markus_sabadello 17:02:27 present+ 17:03:03 scribe+ 17:03:22 Topic: PR progress 17:03:31 brent: today we're looking at PRs that close out issues. Jump on the q to discuss 17:03:36 q? 17:03:47 Orie has joined #did-topic 17:03:52 present+ 17:04:06 JoeAndrieu has joined #did-topic 17:04:06 manu: I have updated all of the issues, I have some questions 17:04:22 ... there are 5 horizontal review issues, not touching those yet 17:04:32 ... my expectation chairs and staff is that we are going to cover them at the tail end of the editorial cycle 17:04:39 ... people will make one final pass to make sure they're good, correct? 17:04:39 dmitriz has joined #did-topic 17:04:47 present+ 17:04:51 brent: brief update, as far as I am aware horizontal review opportunities have been offered to all of these groups 17:04:55 ... PING met to discuss us earlier this month 17:05:02 ... they have yet to publish minutes about that so I don't know what they said 17:05:08 ... but looking at their slack they haven't mentioned raising issues 17:05:14 ... if they had something they wanted to say they would have said it by now 17:05:19 ... the other horizontal review has been completed 17:05:34 ivan: the main reason we kept these open is because we will have to give a report on those when we make the request for CR transition 17:05:46 ... we will have to make a reference to each of these because each say they cleared horizontal review 17:05:51 ... they only reason they were kept open is administrative 17:05:57 manu: deferring to the chairs and staff on what they want to do.. 17:06:06 ivan: close as soon as chairs and me finalise the CR request 17:06:08 manu: sounds great 17:06:18 ... I have also marked a number of issues as defer-v2 17:06:24 ... we let everyone know we were going to do this 17:06:41 ... want to make sure we didn't mark anything that was being actively worked on, that someone got a PR in last minute that addresses one of these 17:06:51 JoeAndrieu: there is one for privacy considerations for service endpoints 17:06:55 ... there is a PR in 17:07:16 manu: anything else on this list? herd privacy? 17:07:19 JoeAndrieu: I commented 17:07:35 manu: jonathan for the DIIPS? no on the call 17:07:39 ... ACLU responses.. joe and adrian? 17:08:01 JoeAndrieu: that's appropriate.. it's a very subtle point and we've tried to address it in some of the use case stuff, nothing that has boiled up to spec, deferring is appropriate 17:08:07 manu: when should DID params be dropped, Orie? 17:08:12 q? 17:08:23 Orie: I think this has sort of been solved by the pulls to the key rotation section and examples 17:08:26 ... we could safely close it 17:08:39 ... generally query params in DID URLs are a poorly supported and understood feature and anyone building on this is playing with fire 17:08:48 manu: good to know, we'll keep it open and defer, because there isn't a definitive yes we dealt with that 17:08:52 ... and bring it up for a new WG 17:09:02 ... this public key id type duplication is defer v2, that's mike jones 17:09:10 ... A couple i did not defer 17:09:13 ... because they are in process 17:09:23 ... shigeya is updating the architecture diagrams, that PR is waiting 17:09:29 ... that'll be in there, it's editorial 17:09:45 ... the determinisitic canonical cbor hasn't been merged yet? that's strange, I think it was, just missed this one 17:09:56 ... proving control sections is an editorial thing that needs to be fixed, can be done in a week or two 17:09:59 ... PII is correct, editorial 17:10:03 ... IANA considerations there's a PR in 17:10:21 ... wasn't merged because of merge conflicts 17:10:36 ... things like this are okay, they're not disruptive to what the editors are doing, they improve the spec 17:10:42 ... so I wasn't going to defer this one unless people objected 17:10:51 ... those are all the issues, we're down to like 18 17:10:59 ... many of them are addressed. Only deferring like 5 issues, which is pretty amazing 17:11:15 ... Questions for the group, are you okay with the state o fthings? Are issues being processed per expectation? 17:11:33 brent: I'm very pleased. 618 is just a continuation of what's already happening 17:11:35 ... not a new thing 17:11:42 ... and it's editorial 17:11:49 ... bug fixes 17:11:50 manu: agree 17:11:53 ... On to the PRs 17:12:04 ... The massive editing cycle has begun 17:12:10 ... there are 2 PRs I want to talk about in a bit 17:12:24 ... I have started marking all of the PRs as editorial, substantive or non-substantive 17:12:35 ... this is not something we really need to do, but it's a training exercise for the group 17:12:49 ... anything marked as substantive, if we do that when we're in the CR process it is almost certainly grounds for doing another CR 17:12:52 ... it's bad 17:12:59 ... any time you see this label after we go into CR it's not a good thing 17:13:07 ... Want to show what those types of PRs look like vs the non substantiveones 17:13:14 ... which can be normative, but don't change implementations 17:13:25 ... eg. this non-substantive change removes duplicated normative rquirements 17:13:32 ... we state you must do x, and later on we say you must do x 17:13:36 ... same statement repeated twice in two places 17:13:42 ... we remove one, implementations wouldn't have to change 17:13:53 ... A substantive change is we made normative changes and everyone's implementation is going to have to change as a result 17:14:06 ... In one of these, we had no normative reqs around DID URL syntax 17:14:11 ... we said what it is but didn't enforce it 17:14:20 ... so added a normative statemetn that says this is the syntax you musts conform to 17:14:28 ... everything that's editorial is meant to be editorial - feel free to disagree 17:14:39 ... the editors can miss stuff pretty easily with mass cleanups, accidents happen 17:14:51 ... or a change where the editor in their mind has a good argument for why it's editorial but it may not be clear from the PR 17:15:02 ... this is the editors attempts at classifying the PRs and highlighting which ones people should pay mor eattention to vs not 17:15:06 ... questions? 17:15:06 q? 17:15:19 ... everyone happy with this process for the next 3 weeks? 17:15:24 brent: comments or questions about the process? 17:16:03 present+ dmitriz 17:16:04 ... From my perspective we're following the same notions that we followed all along. We want to ge tthings doen as reasonably quicly and efficiently as we can, with minimal process 17:16:15 ... which is why our primary process directive is that if you see something in that shouldn't have gone in, let us know 17:16:19 ... it rarely will be too late 17:16:26 ... with that in mind, we need to keep up with these things 17:16:41 burn has joined #did-topic 17:16:42 ... those who have opinions need to state those opinions. Subscribe to the repo and you'll get email notifications 17:16:48 manu: timing of these PRs 17:16:48 q+ 17:16:50 present+ JoeAndrieu 17:16:56 present+ 17:17:00 ... we had said earlie rthis week during the main call that we'd like a 24 hour turnaround but it may take longer 17:17:00 zakim, who is here? 17:17:00 Present: markus_sabadello, ivan, brent, shigeya, manu, rhiaro, Orie, dmitriz, JoeAndrieu, burn 17:17:02 On IRC I see burn, dmitriz, JoeAndrieu, Orie, brent, markus_sabadello, RRSAgent, Zakim, justin_r, ivan, shigeya_, ChristopherA, manu, dlongley, rhiaro 17:17:05 ... the editorial pass is happening top to bottom in the spec 17:17:13 q- 17:17:16 ... that means the top part of the spec has a whole bunch of PRs in on editorial cleanup and changes 17:17:31 ... I'm tagging people that probably have comments on each one of those sections and everyone is doing a great job engaging 17:17:34 ... thansk for reviews, they really help 17:17:41 ... these PRs are going section by section 17:17:51 ... it's ideally only three to eight paragraphs of text in each PR 17:17:58 ... a lot of it is formatting, line lengths 17:18:02 ... but some do rewording 17:18:04 ... if you're tagged please do the review 17:18:13 ... I'm trying very hard to not merge things in that have not had at least two other parties do a review 17:18:23 ... the whole 24 hour thing, some have been floating for 2 days now 17:18:32 ... some is that the editors don't need it merged right away so we're giving a bit mor etime 17:18:42 ... as a genearl rule I'm tring not to merge things that dont' have multiple reviews 17:18:52 ... anything that is a substantive change wll probably be left out there for at least 48 hours 17:18:56 ... espeically if it has people objecting 17:19:01 ... any objecting across any PR is not merged 17:19:08 s/genearl/general/ 17:19:26 ... all that to say, the rule I'm working with is if at least two different people have reivewed the PR in addtion to the editor of the PR and everything looks good, no objections, and changes adopted, I'll merge it in 17:19:32 ... that usually takes around 48 hours, based on data we have so far 17:19:41 ... any concerns, questions around timing around PRs? 17:19:54 ... we can just delve into PRs that people are working on 17:20:00 ... There are 2 that have raised the question around ADM again 17:20:12 ... markus, would you like to provide a background on both of these PRs and the current concern? 17:20:16 https://github.com/w3c/did-core/pull/596 17:20:28 markus_sabadello: one of these PRs, production and consumption 17:20:57 ... trying to show how production and consumption works and what the relationship is between the data model and the individual representations 17:21:03 ... the data model defined in section 4 and the representations in section 6 17:21:04 Suptopic: production and consumption issue @pr 596 17:21:08 ... the data model we define as an infra map 17:21:14 ... not json, not cbor, not xml, it's infra notation 17:21:18 s/Suptopic/Subtopic/ 17:21:33 ... the diagram is attempting to show how this abstract data model by going through a production process gets to a concrete representation in jsonld, json and cbor 17:21:46 ... that's it, the discussion and controversial aspect is around wehther @context is included in the ADM 17:21:58 ... if ADM has to be present in the top left corner in order to produce the jsonld representation 17:22:01 ... that's the discussion 17:22:02 q? 17:22:13 its not about production... its about consumption... the consumption arrow is where the error is. 17:22:16 q+ 17:22:20 ... I think the consensus after the ADM discussions was the data model, the infra map, can hold @context, or other representation specific entries, but it doesn't have to be there 17:22:38 ack Orie 17:22:38 ... this diagram is trying to show the simple case where the data model contains core properties and other representation specific entries they get added in individual representations 17:22:46 Orie: i'm on eof the people who doesn't think that this is a simple diagram 17:22:51 ... the consumption arrow is the problem 17:22:54 ... the production arrow is fine 17:23:03 ... how methods choose to represent context internally before production occurs, is up to them 17:23:07 ... context is a representation specific concept 17:23:18 q+ to note preservation of properties important in diagram. 17:23:29 ... consumption rules we have spent time talking about preservation of properties an dthe fact that multiple representations means that unregistered properties are all preserved 17:23:30 can i share my screen? 17:23:32 q+ 17:23:45 ... the arrow violates the WG consensus 17:23:54 ... it sounds like @context must be present in the ADM to produce jsonld. I'm not saying that 17:24:01 ... this picture implies somehow youc an consume jsonld and lose an @context 17:24:08 ... we've admitted we're going to conserve all properties 17:24:13 ... I'll object until we can fixt that visulaisation 17:24:22 ... on markus' original point, @context doesn't need to be in the ADM for production 17:24:30 ack manu 17:24:30 manu, you wanted to note preservation of properties important in diagram. 17:24:32 ... but if you're consuming json that contains a member into the ADM and somehow losing it, that is a problem 17:24:39 manu: +1 what orie said 17:24:46 ... it's a difficult balance 17:24:56 ... what we'r edoing here is putting 3 different production/consumption things together 17:25:10 for what it's worth, I am in favor of markus_sabadello 's diagrams and do not agree with Orie 's changes. 17:25:23 ... because the diagram is trying to show production and consumption across multiple representations we should at least put @context in here because in this way, even in consumption in this way, you'd have @context 17:25:29 ... the change request is to put @context in the ADM 17:25:39 ... it makes it possible for the reader to ask the question why is @context disappearing in production here 17:25:42 ... and not here 17:25:44 I would not put `@context` in the ADM... its confusing... I would split up the diagram 17:25:54 ... it could also be that they raise the question fo wait a second you just consumed something where did this @context come from? 17:25:59 ... I think there are down sides both ways 17:26:07 ... but the way it is currently proposed makes it seems like @context appears out of thin air 17:26:12 ... we can't propose that as how this thing works in general 17:26:21 ack markus_sabadello 17:26:32 markus_sabadello: I made another version of this diagram 17:26:47 q+ to say maybe this diagram is trying to do too much (and simplifies too much), or we need to accept that simplification inherently makes things less precise and we should add a note that says look at the spec for the detail 17:26:48 ... a subset of the other diagram that doesn't show all th eproduction and consumption at the same time 17:27:06 ... but shows what happens when you consume the jsonld, and @context is preserved, and you produce a plain json representation and the @context is still there 17:27:17 ... this is the agreement we had after th ediscussion 17:27:22 q+ to like the new diagram -- but also point out that it doesn't have to be that way. 17:27:22 ... I still think it's a mistake, but that's what we agreed 17:27:26 A series of diagrams seems more helpful 17:27:35 q+ to agree with markus 17:27:36 ... I think it's more important to show a diagram that starts with a data model that does not contain any representation specific entries 17:27:49 ... if we put a diagram like this in a prominent space, people would ask why we have something represent specific in an ADM 17:27:54 +1 to markus_sabadello 17:27:57 ... we could have two diagrams 17:28:00 present+ 17:28:06 ... one that looks kind of like the one in the PR and in additon something like this 17:28:12 ack brent 17:28:12 brent, you wanted to say maybe this diagram is trying to do too much (and simplifies too much), or we need to accept that simplification inherently makes things less precise and we 17:28:12 ... that shows preservation of the entries 17:28:15 ... should add a note that says look at the spec for the detail 17:28:33 brent: in any simple diagram of a complex system you're going to be making generalisations and making things less precise 17:28:36 q+ 17:28:47 ... I think either we clarify with the second diagram that says in this specific case this is what the spec text says 17:29:02 ... or add a sentence that says this diagram is a simplified visualisation and pay attention to spec for specifics 17:29:02 ack manu 17:29:02 manu, you wanted to like the new diagram -- but also point out that it doesn't have to be that way. 17:29:06 manu: +1 to what brent said 17:29:12 ... and +1 to this diagram, I like it much better 17:29:23 ... having a series of diagrams will be easier for people to not get confused over 17:29:35 ... I was going to say in this diagram I'd be fine also with the second thing eliminating @context 17:29:41 ... I know that's controversial and some people would disagree 17:29:47 ... it is an issue with roun dtripping 17:29:57 ... if all of us can look at this diagram and say we're fine with that being in the spec I think we're done 17:29:59 ack Orie 17:29:59 Orie, you wanted to agree with markus 17:30:06 Orie: I think a series of diagrams would help 17:30:13 ... we need the other picture. This picture work sfor jsonld production and consumption 17:30:19 q+ 17:30:22 q+ 17:30:26 ... deleting @context will work for json production and consumption. Maybe there's a CBOR version to show as well 17:30:41 ... It'd be better to tackle the complex case of what happens if you start with json and you want to produce jsonld in a diagram that's just about that 17:30:47 ... as opposed to a diagram with 6 arrows and hiding what's going on 17:30:48 ... that's confusing 17:31:05 ... as far as manu's proposal for allowing you to produce did+json tha tdrops a property, that violates the consensus of the WG 17:31:15 ... but I'm in favour of a picture of this that's just vanilla json that never has an @context in it ever 17:31:15 present+ 17:31:17 ack ivan 17:31:29 ivan: I am sorry but I don't like the one 17:31:41 ... if I am coming from the outside what I see is that the application did+json and did+ld+json is exactly the same 17:31:54 ... if I know a little bit about jsonld then I don't know what the @context does and plays what role on the right hand side 17:32:05 ... if I remember well, we separated the representatoin specific properties form what is in the core set 17:32:12 ... what about making some sort of a diagram which has the data model as it is now 17:32:17 ... without the context 17:32:26 ... and in that box in the upper left, a separate entry somehow for representation specific properties 17:32:29 ... where the context is present 17:32:32 ... we do separate these things 17:32:37 Isn't it possible to keep representation-specific property as part of didDocumentMetadata ? (I mean, split the upper-left box)... 17:32:41 ... context is specifically called out as a special thing in the spe 17:32:42 ...c 17:32:48 ah, that's what ivan is saying I guess... 17:32:52 ... in the representation on the data model there is something else that should be part of the diagram 17:32:57 q+ to partially agree with ivan 17:32:59 ... when I produce the json I use it or don't use it 17:33:02 ... and things become clearer 17:33:06 ... but merging the two things for me is a mistake 17:33:18 ack justin_r 17:33:20 q+ to note about namespaces. 17:33:21 justin_r: +1 to ivan 17:34:20 ... the underlying problem people seem to be having with th eoriginal diagram is that the jsonld crowd sees this as okay so obviously you're starting with the thing in the lower left and everything else is derivative and you're dropping properties 17:34:24 ... that's not an accurate reading of the diagram 17:34:32 ... which means the diagram is misleading if people can read it that way 17:34:38 ... what this is trying to show is that there is a DID doc which is the thing in the upper left 17:34:47 I agree with Justin... the diagram is confusing. 17:34:50 ... that can go in and out of representatons using the production and consumption rules specific to those representations 17:35:02 ... I like ivan's idea of putting the representation specific properties into a separate bucket in the ADM 17:35:09 ... we had long discussions about these being different things 17:35:12 ... than did doc properties 17:35:16 ... I think that would help to tell that story 17:35:24 I also agree with Ivan and Justin's proposal to store @context in the ADM in a seperate bucket. 17:35:34 ... because I completely agree that th eother one that has @context in both the ldjson and json isn't telling an accurate story either 17:35:42 ... it is telling a limited story of limited usefulnes to make one small point 17:35:48 ... about carrying this @context value through 17:36:01 ... if you're producing did+json then @context is a meaningless field, which will be held next to the data model, not in the data model 17:36:26 ... and to go in the opposite direction to produce ld+json from a json source, you would need to create the context probably based on that field that was passed in 17:36:29 ... but potentially not 17:36:38 ... because there will be plenty of cases where the plain json has no semantic labelling in it 17:36:41 q+ to "meaningless field" -- our JSON Schema pays attention to @context in both JSON-LD and JSON-only -- we injest as JSON. 17:36:46 ... and that needs to be added by the ld processor on production 17:37:01 q+ to note substantive changes to spec that would need to be made. 17:37:01 ... I get where the LD community is coming from, but that's not the story I believe markus was trying to tell with the original diagram 17:37:06 ... which is why I am against the proposed changes 17:37:07 ack markus_sabadello 17:37:23 markus_sabadello: I can update the PR with two diagrams based on that 17:37:42 ... what's most important for me is to make the point that you can start with the instance of the ADM that does not contain any representation specific entries and then produce all of the conformant representations from it 17:37:46 +1 to get rid of the consume arrows 17:37:50 ... maybe orie and manu would be okay if this diagram did not contain the consumption arrows 17:37:58 ... or it would be greyed out and this would show that based on th eADM you can produce all of these 17:38:09 ... and as a second diagram we could have representation specific entries that are preserved 17:38:24 ... I can also do what ivan said, to illustrate that this @context is part of the data model but is representation specific entry 17:38:30 ... I could do that if it's acceptable to have two diagrams 17:38:38 ... the second PR that's open is about the same thing 17:38:45 ... all the concerns we heard apply equally to the other PR 17:38:49 ... which is another diagram more to do with resolution 17:38:57 ... but same underlying issues, I could also split that into two diagrams 17:39:11 ack Orie 17:39:11 Orie, you wanted to partially agree with ivan 17:39:14 Orie: Splitting consumption and production up would help a lot 17:39:35 what if we added a description to the diagram that says: "This diagram illustrates how the abstract data model might be used to produce each representation. For specific details on the production and rules for each representation, please refer to ..." 17:39:36 ... in the production case, going from a box that has context floating next to the ADM to a json representation that does not contain a context, that's very valid and exactly what we agreed to in the WG 17:39:46 ... if we remove the consumption arrows we'll be on the way to solving issues 17:39:50 ... we already put @context in its own special box 17:39:57 ... it's a property that is a representation specific property allowed in the ADM 17:40:20 ... some of the language jusing was using is challenging because we only have one bucket to put ADM entries, so we're shoving representation specifc entries and DID doc entries into the same bucket 17:40:23 ... at this point we're stuck on that path 17:40:38 ... but it doesn't mean we can't have a nice clean picture of production and consumption that is respectiv eof the native representatons 17:40:42 ... I don't agree that it's an LD thing 17:40:49 if it's not an LD thing then just drop @context :) 17:40:52 ... I think it's a JSON preservation of properties in a consistent manner 17:41:04 if it's not an LD thing then just drop foo :) 17:41:10 q+ to talk about this special case and "foo" 17:41:11 ... if I add foo or $schema and do consumption then production, I expect those properties to preserverd by JSON 17:41:14 ^^ see the problem w/ that line of argumentation? 17:41:15 ... I care more about the json rules making sense 17:41:24 ... json needs to preserve properties when being consumed and produced through the ADM 17:41:25 ack manu 17:41:25 manu, you wanted to note about namespaces. and to "meaningless field" -- our JSON Schema pays attention to @context in both JSON-LD and JSON-only -- we injest as JSON. and to note 17:41:26 q+ 17:41:28 ... substantive changes to spec that would need to be made. 17:41:36 manu: we're getting to something maybe workable 17:41:43 ... there are normative statemetns int he spec that are probably going to have to change 17:41:46 ... I think it might be for the best 17:42:03 ... our data model keeps thinking that, sort of asserts that the DID doc is the only thin you can express and that's the root 17:42:13 ... with the work on the resolution sectoin and this stuff I think it's clear that we want mor ethan one bucke 17:42:14 ...t 17:42:26 ... the dat amodel is capable of expressing a number of things - metadata structure, DID doc, Verificaton method structure 17:42:33 ... or abucket for representation specific properties/entries 17:42:46 ... as long as the group is okay with this direction, I can make some substantive changes that create multiple buckets 17:42:51 ... make the ADM a bit more genralised 17:42:59 ... and I think that will address a number of issues throughout the spec 17:43:09 ... I think there's something workable here 17:43:16 ... markus if you rework the diagrams 17:43:19 ... and I work on some of the text 17:43:29 ... we may be able to come to something mor egeneralized that can be applied more cleanly across the entire spec 17:43:34 ... +1 for the changes requested 17:43:40 ... and making the diagrams more specific 17:43:41 ack justin_r 17:43:41 justin_r, you wanted to talk about this special case and "foo" 17:43:48 justin_r: respond to the 'foo' property thing 17:44:04 ... this is, as has been previously argued many times, as we've talked about, it really is a different kind of thing 17:44:08 selfissued is not here... but he would agree with me :) 17:44:18 ... say your source doc is coming in in json and has a proeprty named @context: true 17:44:24 q+ to say @context "is a different thing" -- JSON Schema 17:44:29 ... this is acceptable, it gets dropped into the ADM with a property named @context with a boolean value of true 17:44:33 ... all of that works 17:44:39 ... when you go to produce that into ld+json 17:44:42 ... everything is legal so far 17:44:54 ... when you go to produce ld+json that LD producer has to supply a context field and it has to have a valid value 17:45:02 ... and it is programmatically going to have several sources of information for the value of that field 17:45:17 ... extra properties dumped into the data model that the consumer didn't know how to do anything special with, like @context, is going to be one of those 17:45:20 q- 17:45:30 ... the problem is that the LD produce absolutely has to understand the @context property if it shows up in the ADM 17:45:37 ... and be able to process it with a correct value 17:45:44 ... so this is not to say this is just about property preservation 17:45:45 ... it's not 17:45:52 ... pretending that it is is not helpful to the conversation 17:46:01 ... what we're really talking about here is how do we create an LD json document 17:46:12 ... when we have different sources of information for what goes in the context field 17:46:18 ... whic is semantically significant to jsonld, but not necessarily to anybody else 17:46:18 I disagree with Justin, but won't belabor the point -- the WG has discussed this many times, and has shown how @context is useful in JSON-only. We're just not going to agree on this. 17:46:24 I obviously don't agree with justin_r, luckily we both appear to agree to the application/did+json production and consumption rules in the spec. 17:46:31 ... all of these examples of what you want to happen are coming form places where you're getting good data 17:46:38 Yep, agree, let's just leave it there. 17:46:39 q+ 17:46:40 ... but you're not guaranteed to get good data from other implementations, other representations 17:46:48 ... this is a dangerous road to walk down 17:46:57 ack markus_sabadello 17:47:06 markus_sabadello: I will try to work on updates to the diagram 17:47:15 ... manu I was surprised to hear you think normative statemetns have to change 17:47:16 apparently we disagre on what the WG has agreed to as well 17:47:21 ... I think we're already saying this n the spec 17:47:27 ... we say the data model can contain two kinds of entries 17:47:32 q+ to note Section 6.1 17:47:35 ... I thought that was what the third diagram was bout, which is less controversial 17:47:49 ... in an open PR that already shows the specification today, that the data model can hold the core properties and also representaiotn specific entries 17:47:58 ... I look forward to any suggestions on how to improve also the text 17:48:06 ... I want to show th eother diagram this is controversial but the same underlying topics 17:48:14 +1, I don't see any need to change normative statements from these diagrams 17:48:23 ... the same thing sa before, productoin and consumption fo different representations, but adds a resolution here 17:48:33 q- 17:48:38 ... resolve which returns ADM and resolveRperesentation whic h returns a representation 17:48:54 ... probably the same issue here, which if you consume a jsonld the @context shoudl be preserved 17:49:16 ... so i made another version, one of the sequences is you resolverepresentation you get back jsonld, consume that and produce json with @context preserved 17:49:22 ... I can also try to update this PR with input that was given 17:49:26 ack manu 17:49:26 manu, you wanted to note Section 6.1 17:49:32 manu: +1 to that diagram, very helpful 17:49:35 ... I'd be good with that 17:49:44 ... The normative statements I'mtalking about, we just want to be crystal clear about this discussion 17:49:51 ... in section 6.1 we say: 17:49:54 We say this in 6.1 currently -- "The representation MAY define representation-specific syntax that can be stored as entries in the data model. These entries are included when consuming or producing to aid in ensuring lossless conversion." 17:50:16 ... when we say data model we have other language tha tsays the data model is the DID doc 17:50:18 "stored as entries in the data model" => DID Document : INFRA 17:50:21 +1 to manu 17:50:22 ... we are not clear at all that there could be different buckets 17:50:38 ... the clarification we need to make is what those different buckets are and potentially where the production rules pull from when they serialize and deserialize 17:50:48 ... there are normative statemens in the spec right now that lead to the discussion we're having 17:50:55 ... orie and I being surprised about the diagram 17:51:08 ... we've had the discussion, seems like everyone is on the same page, let's just make it explicit about how the group thought about it 17:51:17 ... maybe not every single clarificaton is a normative statement, but there might be a few 17:51:26 ... I'll put them in as a substantive edit and see if it helps us align more 17:51:33 ... everyone can look at it 17:51:42 brent: another PR? 17:51:53 q+ to ask shigeya somethign 17:51:58 ack manu 17:51:58 manu, you wanted to ask shigeya somethign 17:52:17 Topic: Questions on Shigeya's diagrams 17:52:18 manu: shigeya, thank you for putting those diagrams together, very helpful for the architecture 17:52:21 +1 big thanks to Shigeya for his PRs 17:52:26 ... one concern is that it's a black and white diagram, colour coding may help 17:52:35 ... the simplified diagram still has a number of arrows that look scary 17:52:42 ... I know the point was providing relationsihps between everything 17:52:53 ... can you provide the source other than svg? google doc? that would allow the editors to iterate? 17:52:56 shigeya_: sure 17:53:04 ... it's in my branch of my repo 17:53:06 ... already available 17:53:22 ... if you want them in main, I can commit, or mail it to you 17:53:33 manu: ideally the sources are in the repo.. what tool are you using? 17:53:38 shigeya_: using ?? on Mac 17:53:49 ... it can export several formats, I will inform you which format is available 17:53:53 scribejs, pr 612 17:53:53 s/??/OmniGraph/ 17:54:02 manu: if it can get into google draw, that seems to be a useful thing 17:54:03 ... if not we can recreate it 17:54:08 ... we just want to get it into a format we can iterate on 17:54:21 ... The other quesiton was layout with the diagram, I'm sure you've tried to lay it out in a way that's easier 17:54:30 ... I'm wonderig if we can simplify further and reduce arrows to the minimum 17:54:38 s/quesiton/question/ 17:54:43 ... it could be that DID URL and DID URL dereferencing could be a different diagram, down in the URL dereferencing section 17:54:48 ... that may simplify the diagram further 17:54:58 ... ideally I think we want 5 concepts in the diagram. 6 to 7 is a bit much 17:55:03 ... at thih spoint we have 15 including the arrows 17:55:08 ... I really appreciate all the work in the diagram 17:55:14 ... trying to see how aggressively simplified we can get 17:55:15 +1 to the idea of separate similar diagrams for each concept 17:55:23 ... so people look at the diagram and see it as simple on the surface 17:55:31 brent: any other feedback on this? 17:55:56 shigeya_: manu says you were going to edit the drawing for colours 17:56:04 ... if there's any colour scheme you want I can add before I provide you? 17:56:10 manu: I don't have any suggestions.. whatever looks pretty 17:56:18 shigeya_: sure. I suggest some warmer colour scheme, my preference 17:56:26 manu: thank you 17:56:27 +1 to black and white 17:56:53 Topic: AOB 17:57:02 manu: request that people review the PRs, especially substantitive 17:57:18 brent: want to introduce one? 17:57:33 manu: DID URL syntax.. cosmetic changes, putting things in the table 17:57:44 ... the normative change that we didn't have before is that all DID URLs must conform to the DID URL syntax ABNF rules 17:57:53 https://github.com/w3c/did-core/pull/621 17:57:54 scribejs, pr 621 17:58:13 ... if you look at thE PR it can be lost with all th eformatting changes 17:58:17 ... this is the normative change to look out for 17:58:36 ... search for the word MUST and see if something has been added or deleted, and see if you agree 17:58:48 ... I do try to summarize why it's been marked as substantitive in the PR 17:58:56 brent: we'll close, thanks all 17:59:06 ... Please look closely for the next few weeks at our repos, a flurry of activityw ill be present 17:59:12 ... we hope you can all remain engaged 17:59:28 zakim, end meeting 17:59:29 As of this point the attendees have been markus_sabadello, ivan, brent, shigeya, manu, rhiaro, Orie, dmitriz, JoeAndrieu, burn, justin_r 17:59:29 RRSAgent, please draft minutes 17:59:29 I have made the request to generate https://www.w3.org/2021/02/11-did-topic-minutes.html Zakim 17:59:31 ... thanks all! 17:59:33 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 17:59:37 Zakim has left #did-topic 17:59:52 rrsagent, make logs public 18:00:02 rrsagent, please excuse us 18:00:02 I see no action items