Meeting minutes
yamdan: Is there a way to use a robot to do the automatic scribing?
pchampin: There are facilities, if we make a discision. There's Zoom's auto captioning.
… This might not be as productive as human scribing.
manu: I wrote the system for CCG which uses a bunch of different systems working together.
… we weren't able to use the Zoom output as it's proprietary.
… The output of the CCG system is still pretty poor.
… We could meet on that bridge, but it's flakey. I'd suggest that we stick with human scribing.
phila: We understand that not everyone can handle this, so I don't really expect people to scribe where it's too difficult.
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.
… 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.
<manu> The explainer is here: https://
phila: The output of the CCG has been published as a final report. What do we need to do to get the 2015 draft out.
gkellogg: I imported the document.
gkellogg: I imported the doc. I understand that the WG wants to publish the FPWD based on that.
… My understanding is that we want to publish the current CG report in its current state as a FPWD.
gkellogg: I've been going through one accepted PR was to update it to make it appropriate for the CCG
… Made a PR to make it appropriate to the WG (instead of the CCG).
… working on another PR that will more comprehensivley annotate and get it in line with expectations
https://
https://
gkellogg: Talks a little about https://
gkellogg: Wants to see more specific approvals
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
… but it depends on a WG decision
gkellogg: before we can do a FPWD, we need more describtive text, but also examples, images and diagrams
… Even though we have not make a final decision on the output of the c14n, this can serve as a basis.
phila: yes, the FPWD could even be a half-empty document.
… In this case, the danger is the opposite.
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.
<pchampin> :)
phila: We probably need more issues linked into the doc to show that there are issues to be dealt with.
manu: I think the descriptive content is great. +1 to getting an FPWD out sooner rather than later.
… There is a way in respec to add all open issues, not just those explicitly linked.
… Ideally publish before the end of the year.
… It's great that we have this pulled into the group, but the history doesn't go back to the beginning.
… There are C14N edits going back to 2010.
1+
manu: I'd like to graft that history into our repo so that everything is in one place.
… I'll take an action to do that at some time.
<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.
gkellogg: we only imported the text, not the tests or other things...
… We started from the last comment of the CCG spec.
… My thought was that we are referencing the CCG spec as an input, providing a ref to the repo where it exists.
… Not sure how practically useful it would be to have that history in our own repo.
… But I'm fine either way.
phila: Manu discussed patents, and I have some scars there; I'm interested in doing whatever we can do to maintain our claim.
… Anything that supports the process I'm in support of.
<Zakim> manu, you wanted to speak to grafting mechanisms... it'll be rebase/manual maybe a merge.
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.
… It took me an hour to trace back to 2010. Let's try to include as much as we can.
… It shouldn't block any work. Doesn't need to be a rebase.
gkellogg: maybe Manu and I can discuss this offline.
… As I remember, we moved a repo around.
manu: the JSON LD spec has the algorithm.
gkellogg: it would be worthwhile to descrtibe both Aidan's and Dave's algorithm in equivalent terms
phila: A couple of things that must be done, really necessary.
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.
<manu> +1 to phila's proposal above ^
dlongley: I'm fine with that.
gkellogg: I do have some questions about variable names (different in the CG report and the report)
… Dave and I can discuss that.
phila: Gregg will talk with Dave next week, so roughly by the end of next week there will be a document we can use.
gkellogg: in the meantime I encourage people to look at the existing PRs
… and to comment them
… even if you are not formally requested to review the PR
phila: If you're in the WG, please take part an help with the work.
… For others, please speak up if you' have any changes you'd like to make.
… It's the last 10% that takes 90% of the time.
dlehn1: What are we doing with the tests.
gkellogg: I do want to move those tests over eventually.
… Moreover, making sure that the tests are properly linked in the document (as Ivan showed during TPAC) will be more work.
dlehn1: It might get confusing.
gkellogg: In the meantime, we can make changes to the CCG repo.
gkellogg: I have experienced this text-to-test link in the YAML-LD documents.
… Plus some github automation for links from spec to manifest
… It is useful, for every normative statement (not only MUST/SHOULD) to find where they are tested
gkellogg: eventually the test suite will be moved over to our repo, and then we will link
<Zakim> manu, you wanted to note we need to move tests over to RCH, separate repo.
gkellogg: but not before FPWD
manu: +1 for moving over the test suites, but FPWD should come first.
<Zakim> phila, you wanted to ask more about tests
manu: I'd expect that we'll have another discussion around tests. Shouldn't modify CCG tests until they're moved over.
dlehn1: I need to make some changes someplace, the CCG is the only place to do that right now.
phila: At the moment, you can only do it there, but IP is different, process is different.
pchampin: We're talking about a CG repo. The CG is already subject to some IP rules, so there is some protection.
phila: My belief is that no one should top working on tests, but ASAP (after FPWD) we should move them over.
gkellogg: another issue, that we are facing with JSON-LD, is that web search point people to the CG work
… this should point very clearly to the WG work
phila: Any resistance to that? (doubtful).
dlongley: We're the same people, so shouldn't be a problem.
gkellogg: we don't want it to go away, we want to keep it for history
… but we need search engines to prioritize the WG
phila: We need to be sure that the CCG work is preserved.
https://github.com/w3c/rch-rdc/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc
Issue 4 https://github.com/w3c/rch-rdc/issues/4
phila: This one we've talked about before. Can we decide.
… I think there's agreement that the output of C14N is an abstract dataset.
gkellogg: some time ago I came up with a concept of a dataset with fixed blank node identifiers
… in order to stay away from the serialization itself
… but does it work with the semantics?
pchampin: I think it's not quite accurate. Blank nodes in the abstract syntax do not have labels.
… You can't point to blank nodes, so that's why it's problematic.
… We're inventing something to make this work.
dlongley: Practically speaking, people using the algorithm are going to want something abstract, or something that can be directly fed into an algorithm.
… Perhaps there's a flag.
gkellogg: this is a perfect opportunity to define an issue and point to it in the spec
sebastian: I'd like note that the SPX algorithm jumps straight from an abstract syntax tree to a serialized output.
… 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
<Zakim> manu, you wanted to note defining the "processing pipeline"
sebastian: That's a reason to have a serialized output.
<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)
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.
… transform -> hash -> re-label.