15:01:56 <RRSAgent> RRSAgent has joined #rch
15:01:56 <RRSAgent> logging to https://www.w3.org/2022/10/26-rch-irc
15:02:02 <phila> zakim, start meeting
15:02:02 <Zakim> RRSAgent, make logs Public
15:02:04 <Zakim> please title this meeting ("meeting: ..."), phila
15:02:19 <phila> meeting: RCH bi-weekly meeting 2022-10-26
15:02:19 <pchampin> present+
15:02:28 <aalobaid> aalobaid has joined #rch
15:02:29 <dlongley> present+
15:02:30 <gkellogg> present+
15:02:34 <phila> present+
15:02:38 <phila> chair: phila
15:02:41 <yamdan> present+
15:03:05 <phila> Agenda: https://www.w3.org/groups/wg/rch/calendar#card-51e8f278-b556-4090-b538-7928b3c628b6-20221026T110000
15:03:49 <gkellogg> scribe+ gkellogg
15:04:40 <gkellogg> yamdan: Is there a way to use a robot to do the automatic scribing?
15:05:04 <gkellogg> pchampin: There are facilities, if we make a discision. There's Zoom's auto captioning.
15:05:19 <gkellogg> ... This might not be as productive as human scribing.
15:05:39 <gkellogg> manu: I wrote the system for CCG which uses a bunch of different systems working together.
15:05:50 <gkellogg> ... we weren't able to use the Zoom output as it's proprietary.
15:06:06 <gkellogg> ... The output of the CCG system is still pretty poor.
15:06:23 <gkellogg> ... We could meet on that bridge, but it's flakey. I'd suggest that we stick with human scribing.
15:06:46 <manu> manu has joined #rch
15:06:50 <manu> present+
15:06:54 <gkellogg> phila: We understand that not everyone can handle this, so I don't really expect people to scribe where it's too difficult.
15:07:22 <dlehn1> present+
15:08:32 <gkellogg> phila: Thanks to pchampin for putting the explainer in a GH repo. We may want to extend it and put it into a Use Case document.
15:09:18 <gkellogg> ... I didn't actually see a specific use case that says this is really important for VC. We should add that as a use case.
15:09:55 <manu> The explainer is here: https://github.com/w3c/rch-explainer
15:10:11 <gkellogg> ... The output of the CCG has been published as a final report. What do we need to do to get the 2015 draft out.
15:10:14 <gkellogg> q+
15:10:18 <pchampin> scribe+
15:10:20 <phila> scribe+ phila
15:10:34 <manu> q+ to note some things on repository history for URDNA2015.
15:10:39 <pchampin> gkellogg: I imported the document.
15:10:52 <phila> gkellogg: I imported the doc. I understand that the WG wants to publish the FPWD based on that.
15:11:08 <pchampin> ... My understanding is that we want to publish the current CG report in its current state as a  FPWD.
15:11:15 <phila> gkellogg: I've been going through one accepted PR was to update it to make it appropriate for the CCG
15:11:25 <pchampin> ... Made a PR to make it appropriate to the WG (instead of the CCG).
15:11:39 <phila> ... working on another PR that will more comprehensivley annotate and get it in line with expectations
15:11:58 <gkellogg> https://github.com/w3c/rch-rdc/pull/17
15:12:29 <gkellogg> https://github.com/w3c/rch-rdc/issues/18
15:13:37 <phila> gkellogg: Talks a little about https://github.com/w3c/rch-rdc/issues/18
15:13:51 <phila> gkellogg: Wants to see more specific approvals
15:14:15 <phila> gkellogg: My general practice as an editor - I tend not to wait for group consensus as the result of the PR is still an editor's draft
15:14:31 <phila> ... but it depends on a WG decision
15:15:52 <pchampin> gkellogg: before we can do a FPWD, we need more describtive text, but also examples, images and diagrams
15:16:27 <pchampin> ... Even though we have not make a final decision on the output of the c14n, this can serve as a basis.
15:16:49 <pchampin> phila: yes, the FPWD could even be a half-empty document.
15:17:03 <pchampin> ... In this case, the danger is the opposite.
15:17:06 <gkellogg> phila: The FPWD can be half empty and full of gaps. The fact that we're starting with too much is that we might think we're ready for CR, but we're not.
15:17:14 <pchampin> scribe-
15:17:16 <pchampin> :)
15:17:30 <dlongley> q?
15:17:30 <manu> q+ to note there is a way to "list all issues against the spec" via ReSpec.
15:17:34 <gkellogg> ... We probably need more issues linked into the doc to show that there are issues to be dealt with.
15:18:02 <gkellogg> manu: I think the descriptive content is great. +1 to getting an FPWD out sooner rather than later.
15:18:21 <gkellogg> ... There is a way in respec to add all open issues, not just those explicitly linked.
15:18:33 <gkellogg> ... Ideally publish before the end of the year.
15:18:49 <gkellogg> ... It's great that we have this pulled into the group, but the history doesn't go back to the beginning.
15:19:08 <gkellogg> ... There are C14N edits going back to 2010.
15:19:10 <gkellogg> q=
15:19:12 <gkellogg> 1+
15:19:15 <gkellogg> q+
15:19:44 <gkellogg> manu: I'd like to graft that history into our repo so that everything is in one place.
15:19:57 <gkellogg> ... I'll take an action to do that at some time.
15:20:11 <manu> ack manu
15:20:11 <Zakim> manu, you wanted to note some things on repository history for URDNA2015. and to note there is a way to "list all issues against the spec" via ReSpec.
15:20:21 <pchampin> scribe+
15:20:23 <phila> q+
15:20:28 <phila> ack gkellogg
15:20:36 <pchampin> gkellogg: we only imported the text, not the tests or other things...
15:20:38 <manu> q+ to speak to grafting mechanisms... it'll be rebase/manual maybe a merge.
15:20:50 <pchampin> ... We started from the last comment of the CCG spec.
15:21:08 <pchampin> ... My thought was that we are referencing the CCG spec as an input, providing a ref to the repo where it exists.
15:21:21 <phila> ack me
15:21:25 <pchampin> ... Not sure how practically useful it would be to have that history in our own repo.
15:21:29 <pchampin> ... But I'm fine either way.
15:22:07 <gkellogg> phila: Manu discussed patents, and I have some scars there; I'm interested in doing whatever we can do to maintain our claim.
15:22:32 <gkellogg> ... Anything that supports the process I'm in support of.
15:22:35 <gkellogg> q?
15:22:36 <phila> q?
15:22:41 <phila> ack manu
15:22:41 <Zakim> manu, you wanted to speak to grafting mechanisms... it'll be rebase/manual maybe a merge.
15:23:31 <gkellogg> manu: the reason just pointing back to the CCG spec is that the document has changed locations and names 6 times. You need to drill into the commit hash to find all commits.
15:23:54 <gkellogg> ... It took me an hour to trace back to 2010. Let's try to include as much as we can.
15:24:22 <gkellogg> ... It shouldn't block any work. Doesn't need to be a rebase.
15:24:24 <gkellogg> q+
15:25:16 <pchampin> gkellogg: maybe Manu and I can discuss this offline.
15:25:48 <pchampin> ... As I remember, we moved a repo around.
15:25:59 <gkellogg> manu: the JSON LD spec has the algorithm.
15:26:06 <phila> ack gkellogg
15:27:58 <pchampin> gkellogg: it would be worthwhile to descrtibe both Aidan's and Dave's algorithm in equivalent terms
15:28:19 <gkellogg> phila: A couple of things that must be done, really necessary.
15:29:37 <gkellogg> phila: In my view, we ask gkellogg to do that and announce that it's done and can be reviewed for decision in two weeks.
15:29:41 <manu> +1 to phila's proposal above ^
15:30:17 <gkellogg> dlongley: I'm fine with that.
15:30:19 <pchampin> gkellogg: I do have some questions about variable names (different in the CG report and the report)
15:30:26 <pchampin> ... Dave and I can discuss that.
15:30:54 <gkellogg> phila: Gregg will talk with Dave next week, so roughly by the end of next week there will be a document we can use.
15:31:26 <pchampin> gkellogg: in the meantime I encourage people to look at the existing PRs
15:31:42 <pchampin> ... and to comment them
15:31:59 <pchampin> ... even if you are not formally requested to review the PR
15:32:10 <gkellogg> phila: If you're in the WG, please take part an help with the work.
15:32:34 <dlehn1> q+
15:32:45 <gkellogg> ... For others, please speak up if you' have any changes you'd like to make.
15:33:00 <gkellogg> ... It's the last 10% that takes 90% of the time.
15:33:03 <phila> ack dlehn1
15:33:15 <gkellogg> dlehn1: What are we doing with the tests.
15:33:30 <pchampin> gkellogg: I do want to move those tests over eventually.
15:33:54 <pchampin> ... Moreover, making sure that the tests are properly linked in the document (as Ivan showed during TPAC) will be more work.
15:34:20 <gkellogg> dlehn1: It might get confusing.
15:34:34 <pchampin> ... In the meantime, we can make changes to the CCG repo.
15:35:33 <pchampin> gkellogg: I have experienced this text-to-test link in the YAML-LD documents.
15:36:07 <pchampin> ... Plus some github automation for XX1
15:36:43 <pchampin> ... It is useful, for every normative statement (not only MUST/SHOULD) to find where they are tested
15:37:29 <gkellogg> s/XX1/links from spec to manifest/
15:37:58 <manu> q+ to note we need to move tests over to RCH, separate repo.
15:38:27 <phila> q+ to ask more about tests
15:38:41 <phila> ack dlehn1
15:38:42 <pchampin> gkellogg: eventually the test suite will be moved over to our repo, and then we will link
15:38:49 <phila> ack manu
15:38:49 <Zakim> manu, you wanted to note we need to move tests over to RCH, separate repo.
15:38:49 <pchampin> ... but not before FPWD
15:39:08 <gkellogg> manu: +1 for moving over the test suites, but FPWD should come first.
15:39:09 <phila> q- dlehn1
15:39:20 <phila> ack next
15:39:29 <phila> ack me
15:39:29 <Zakim> phila, you wanted to ask more about tests
15:39:39 <gkellogg> ... I'd expect that we'll have another discussion around tests. Shouldn't modify CCG tests until they're moved over.
15:40:09 <gkellogg> dlehn1: I need to make some changes someplace, the CCG is the only place to do that right now.
15:40:33 <pchampin> q+
15:40:37 <gkellogg> phila: At the moment, you can only do it there, but IP is different, process is different.
15:40:38 <phila> ack pchampin
15:41:23 <gkellogg> pchampin: We're talking about a CG repo. The CG is already subject to some IP rules, so there is some protection.
15:42:01 <gkellogg> phila: My belief is that no one should top working on tests, but ASAP (after FPWD) we should move them over.
15:42:57 <pchampin> gkellogg: another issue, that we are facing with JSON-LD, is that web search point people to the CG work
15:43:01 <dlongley> q+
15:43:07 <pchampin> ... this should point very clearly to the WG work
15:43:11 <gkellogg> phila: Any resistance to that? (doubtful).
15:43:13 <phila> ack dlongley
15:43:32 <gkellogg> dlongley: We're the same people, so shouldn't be a problem.
15:44:15 <pchampin> gkellogg: we don't want it to go away, we want to keep it for history
15:44:30 <pchampin> ... but we need search engines to prioritize the WG
15:44:44 <gkellogg> phila: We need to be sure that the CCG work is preserved.
15:44:57 <phila> Topic: https://github.com/w3c/rch-rdc/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc
15:45:18 <phila> Subtopic: Issue 4 https://github.com/w3c/rch-rdc/issues/4
15:45:51 <gkellogg> phila: This one we've talked about before. Can we decide.
15:46:43 <gkellogg> ... I think there's agreement that the output of C14N is an abstract dataset.
15:46:56 <dlongley> q+
15:46:56 <gkellogg> q+
15:47:02 <pchampin> q+
15:47:05 <phila> ack gkellogg
15:47:06 <dlongley> q-
15:47:43 <pchampin> gkellogg: some time ago I came up with a concept of a dataset with fixed blank node identifiers
15:47:58 <pchampin> ... in order to stay away from the serialization itself
15:47:59 <phila> ack pchampin
15:48:10 <pchampin> ... but does it work with the semantics?
15:48:52 <gkellogg> pchampin: I think it's not quite accurate. Blank nodes in the abstract syntax do not have labels.
15:49:13 <gkellogg> ... You can't point to blank nodes, so that's why it's problematic.
15:49:26 <dlongley> q+
15:49:33 <gkellogg> ... We're inventing something to make this work.
15:49:43 <phila> ack dlongley
15:50:16 <gkellogg> dlongley: Practically speaking, people using the algorithm are going to want something abstract, or something that can be directly fed into an algorithm.
15:50:28 <gkellogg> ... Perhaps there's a flag.
15:50:36 <gkellogg> q+
15:50:39 <phila> ack gkellogg
15:50:59 <manu> q+ to note defining the "processing pipeline"
15:51:03 <pchampin> gkellogg: this is a perfect opportunity to define an issue and point to it in the spec
15:51:15 <pchampin> q+ sebastian
15:51:27 <phila> ack seb
15:52:05 <gkellogg> sebastian: I'd like note that the SPX algorithm jumps straight from an abstract syntax tree to a serialized output.
15:52:33 <gkellogg> ... The reason for that over a Merkle tree is so that the spec continues to be useful, and hash algorithms die when they have problems
15:52:40 <phila> ack manu
15:52:40 <Zakim> manu, you wanted to note defining the "processing pipeline"
15:52:58 <gkellogg> ... That's a reason to have a serialized output.
15:53:25 <dlongley> just for clarity on what sebastian said ... i think we all support separating the hash algorithm as a separate step that runs after canonicalization on the output (or potentially some other transformation of it)
15:53:52 <gkellogg> manu: A processing pipeline might have steps that don't actually do anything. the move between abstract and serialized can be expressed as different processing stages.
15:54:00 <phila> q?
15:54:08 <gkellogg> ... transform -> hash -> re-lable.
15:54:15 <gkellogg> s/lable/label/
15:55:02 <gkellogg> rrsagent, make longs public
15:55:02 <RRSAgent> I'm logging. I don't understand 'make longs public', gkellogg.  Try /msg RRSAgent help
15:55:07 <phila> zakim, end meeting
15:55:07 <Zakim> As of this point the attendees have been pchampin, dlongley, gkellogg, phila, yamdan, manu, dlehn
15:55:09 <Zakim> RRSAgent, please draft minutes
15:55:09 <RRSAgent> I have made the request to generate https://www.w3.org/2022/10/26-rch-minutes.html Zakim
15:55:12 <Zakim> I am happy to have been of service, phila; please remember to excuse RRSAgent.  Goodbye
15:55:14 <gkellogg> rrsagent, pointer
15:55:14 <RRSAgent> See https://www.w3.org/2022/10/26-rch-irc#T15-55-14
15:55:16 <Zakim> Zakim has left #rch
15:55:38 <gkellogg> rrsagent, bye
15:55:38 <RRSAgent> I see no action items