Meeting minutes
<phila> FPWD
Phil: the draft has been published
Ivan: It is not yet published
Phil: it is about to be published
<gkellogg_> https://
Phil: it will be published tomorrow
IIW
Phil: Mark, you can explain to everybody about the recent event.
Mark: There were many sessions about harmonisation and different creditional formats.
<phila> IIW website
Mark: another big topic about Web5.
Mark: Another topic is about identify, signatures, and much more. But nothing specific to this working group.
<TallTed> we've skipped web4, and web3 is still being defined as well
Dan: I had to 2 sessions. One is about SPARQL endpoint and signatures.
Dan: and anonymisation about SPARQL results.
Dan: The second is about the canonicalization (but only as a black box). Mainly from the user perspective.
<manu> Plugfest related to RCH work item output -- https://
Manu: Companies participating and using verified signatures.
<manu> Verifiable Credential Data Integrity 1.0 FPWD: https://
<manu> https://
Manu: 17 credentials issuers.
<manu> Transition EdDSA to VCWG in next few weeks: https://
<manu> Finally, there is a active test suite with multiple implementers: https://
Manu: We will have more test suites from the participants.
Issue
phila: Let us talk about the issues that are recently updated.
phila: Greg. Are there any issues that you would like the group to discuss?
https://github.com/w3c/rdf-canon/pull/40
phila: Any comments on this issue?
ivan: There is a loop in the algorithm that is unecessary.
ivan: We had a discussion about that in issue 23.
ivan: Dave and I agreed that this is unnecessary.
gkellogg_: I took the opportunity to add labels to everystep in the algorithm.
ivan: we need to relabel the steps if the algorithms is changed.
<phila> Proposed Resolution: Accept PR40 that removes the 'simple' processing loop, and close issue 23
<manu> +1
<ivan> +1
<gkellogg_> +1
<pchampin> +1
<phila> Proposed Resolution: Accept PR40 that removes the 'simple' processing loop, and prepare to close issue 23
<manu> +1
gkellogg_: there is some referencing issues that need to be resolved.
ivan: It is a good practice to keep a list of changes to the issue regardless whether the issue is opened or not.
gkellogg_: I will take care of this.
<yamdan> +1
<phila> +1
RESOLUTION: Accept PR40 that removes the 'simple' processing loop, and prepare to close issue 23
phila: any objections?
phila: resolved
https://github.com/w3c/rdf-canon/issues/37
gkellogg_: There is some ambiguity about sorting quads
gkellogg_: there is no formal definition about canonicalised quads
gkellogg_: nquads separaters should be a line terminator or a dot?
<phila> gkellogg_: There's a section in the N triples spec that defines a canonical form. The basic spec allows any amount of white space between components
<phila> ... but you can't have new lines outside the grammar
<phila> ... the canonical form fixes that as a single space character and doesn't discuss newline separator
<phila> ... So erratum would be to include that newline character as part of the canonical form or to describe it only in the canonical form of a document
<TallTed> we might be drilling too far into the details for the moment...
<phila> ... Where a certain no.of quads are used to create a hash - that will help clarify a specific form of these quads without the newline separaor and the terminator
AndyS: I agree with Greg's suggestion.
TallTed: Should we dive into the details about this here.
TallTed: Vocally discussing this here might not be enough.
phila: Understood
https://github.com/w3c/rdf-canon/issues/10
phila: What is the criteria about choosing?
gkellogg_: I don't think it is not up to me to choose the approach.
manu: I agree. We don't have to choose one or the other.
<Zakim> manu, you wanted to note we're not at a fork in the road...
manu: If we decided to do something new, we can do it without disturbing the existing specs
phila: If there is nothing pushing for a change, then we don't have to do it yet.
<Zakim> manu, you wanted to note that it's important to write down what we're optimising for in the current work.
AndyS: Maybe we can add more details about the algorithms.
manu: It is valuable to write down what we optimise (e.g., time complexity, proofs, ...)
<Zakim> gkellogg_, you wanted to discuss a new topic: granularity and approval of future PRs leading to WD publication.
<Zakim> phila, you wanted to support Manu
phila: It is good to include the reasoning for the decisions.
phila: I would like to see a section in the document about the reasons behind the taken decisions.
Granularity of pull requests
gkellogg_: frequency of pull requests and authority for merging pull requests. Maybe we need to discuss the dynamics of this.
<manu> Phil's explanation of the granularity has been my experience.
phila: I think merging several pull requests in the same day will be considered a single change.
manu: I have the same experience and I've never had problems with making several merge requests.
phila: If it is an editorial think, we can go for it greg.
<TallTed> Editors are allowed to edit. :-)
<manu> +1 to depend on Editor's judgement on merging to main. Don't merge unless you're very confident that there won't be objections... make sure you have multiple reviews, etc. :) -- but the Editors already know how to do all of this and have demonstrated to do it well over the past several years. :)
<pchampin> +1
pchampin: I agree that the editors can do changes that is not too large.
phila: Editors should be allowed to edit.
phila: Thanks everyone