Minutes of the 2022-10-26 meeting

Dear all,

here are the minutes for today's meeting, also available at

https://www.w3.org/2022/10/26-rch-minutes.html


pa

                              – DRAFT –
                     RCH bi-weekly meeting 2022-10-26

26 October 2022

    [2]Agenda. [3]IRC log.

       [2]https://www.w3.org/groups/wg/rch/calendar#card-51e8f278-b556-4090-b538-7928b3c628b6-20221026T110000

       [3]https://www.w3.org/2022/10/26-rch-irc


Attendees

    Present
           dlehn, dlehn1, dlongley, gkellogg, manu, pchampin,
           phila, yamdan

    Regrets
           -

    Chair
           phila

    Scribe
           gkellogg, pchampin, phila

Contents

     1. [4]https://github.com/w3c/rch-rdc/

        issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc
          1. [5]Issue 4https://github.com/w3c/rch-rdc/issues/4


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: [6]https://github.com/w3c/

    rch-explainer

       [6]https://github.com/w3c/rch-explainer


    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

    [7]https://github.com/w3c/rch-rdc/pull/17


       [7]https://github.com/w3c/rch-rdc/pull/17


    [8]https://github.com/w3c/rch-rdc/issues/18


       [8]https://github.com/w3c/rch-rdc/issues/18


    gkellogg: Talks a little about [9]https://github.com/w3c/

    rch-rdc/issues/18

       [9]https://github.com/w3c/rch-rdc/issues/18


    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.

   [10]https://github.com/w3c/rch-rdc/

   issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc

      [10]https://github.com/w3c/rch-rdc/issues?q=is:issue+is:open+sort:comments-desc


     Issue 4 [11]https://github.com/w3c/rch-rdc/issues/4


      [11]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.


     Minutes manually created (not a transcript), formatted by
     [12]scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).

      [12]https://w3c.github.io/scribe2/scribedoc.html


Diagnostics

    Succeeded: s/XX1/links from spec to manifest/

    Succeeded: s/lable/label/

    Maybe present: sebastian