Meeting minutes
Repository: webmachinelearning/webnn
Web Neural Network API W3C Candidate Recommendation published
Web Neural Network API CR, 30 March 2023
W3C invites implementations of Web Neural Network API
<chai> 🎉
<ningxin_hu> Cheers!
anssik: Thank you to all the WG participants for your hard work that made this publication possible!
… this has been a collaboration between lead implementers (thank folks at Microsoft and Google!),
… interoperability at its heart (thanks spec and wpt contributors across companies!),
… with feedback from early adopters, web developers, other WGs (thanks WebGPU WG, WebRTC WG!) informing the effort.
… Now is a time to celebrate. It is no small feat to hit CR so it is OK to be a little proud :)
… Then, about the next steps.
… As a concrete first next step, we should configure Echidna to again allow publications in this post-CR world
… This commit disabled publications temporarily https://
… I assume Dom can help configure Echidna the right way
… about the new spec maturity levels on the W3C Rec Track in this post-CR state, my take:
… for "corrections that do not affect conformance" incl. editorial enhancements we publish a CR Draft:
CR Draft
… for "corrections that may [...] affect conformance" or add "new features" we published (a new) CR Snapshot
CR Snapshot
… OTOH, the W3C Process guidance is "a Candidate Recommendation Snapshot should not be published more often than approximately once every 6 months."
… so my understanding is we should set Echidna to auto-publish CR Drafts similarly to WDs earlier and should put a clock running and ~6 months from now publish a new CR Snapshot
… and prior to CR Snaphot we should seek wide review for any substantive changes made since this initial CR. We only request review for the delta, so more light weight.
WebNN - WebIDL and Infra standard conventions
anssik: Zoltan has worked on editorial enhancements to align the spec with WebIDL and Infra standard conventions. Now that the CR is out we plan to start integrating these
The constant() method steps
Spec: Create an operand for a graph constant
Spec: Create a single-value operand from the specified number of the specified type
… PR #365
<ghurlbot> Pull Request 365 Add the constant() method steps. (zolkis)
Zoltan: thanks Ningxin for reviewing this PR and improving it!
… ready for review, needs two approvals
… constants will add two forms, dependency on MLOperand, MLActivation not needed here
… completed algorithms for all the ops in the spec and have ~50 PRs ready
… bikeshed builds OK, all dependencies addressed
[ Zoltan sharing a preview of the improved constant() ]
Zoltan: we keep track of platform objects for given operands and track reference to operand
… we should add arch diagram to the spec to help explain this
… not detailing the algorithms per se e.g. for conv2d just say what to do with inputs and how to get outputs, that is what we want to accomplish with this
… some algorithms are long such as concat()
… we can factor out parts of the algorithms as needed
… lstm() is more challenging one
… asking for feedback how to split this work to make it easy for reviewers, one PR per op or multiple ops per PR?
anssik: thanks Zoltan!
chai: my only recommendation for this type of change to get it in sooner rather than later
… because the change affects the overall style and structure of the document, we should get this in soon before we add more content so new changes can follow this modernized convention
Zoltan: the PRs submitted minimize changes so some of the visual changes presented are not in PRs
… Chai, do you prefer to add visual enhancements first?
Chai: you should look at the changes in two categories: 1) any styling or structure changes that affect every op, do this first 2) enhancing each op that need to be enhanced, this you can group as another category
… otherwise people who want to add new PRs will be blocked on not conforming with the latest styling or structural changes
Zoltan: if I change one method at a time e.g. constant() it does not block adding another op with different styling
Chai: you should keep presentation consistent within the entire specification
… if new ops are added, then you'd need to re-style those new ops added
… prefer styling to be integrated as soon as possible
<ningxin_hu> +1 to make the structure change first
Zoltan: issue is if no algorithms or internal slots are defined then we'd have empty algorithm and internal slot boxes
Chai: if those are optional, then that can wait, I'm waiting about style changes that apply broadly
<ningxin_hu> the algorithm and internal slots to be added could be placeholders there
Chai: anything that is a style change should land as soon as possible
ningxin_hu: thanks Zoltan for this great work, I like the updated visuals!
… I vote for Chai's opinion, make structure changes first, layout each method in this style you have
… I like the algorithm boxes, if not defined yet suggest to make them placeholders
… e.g. lstm could be many PRs, for style changes I recommend land it in one PR
Zoltan: do you like algorithm box like presented?
Dom: prefer to have steps name inside the box
Zoltan: Arguments and returns now in prose, options inside the arguments and returns section
… should I move those out to proper definitions of dictionaries?
… this would be for most algorithms the whole thing, without this I will just change with the styling
ningxin_hu: I think moving options out improves readability
… options are kind of a type definition, moving it out into a separate section I think will improve it and can be reused by other adjecent ops
Zoltan: I can prep a PR for review and import it to other branches I have
<ningxin_hu> That's a significant effort, thanks so much Zoltan
Chai: thanks for this, it is great!
… on the algorithm section, some can be auto-generated perhaps
Zoltan: I tried it actually
Chai: we're going to add more ops in the future, if we need to add this boilerplate and stay consistent it is a huge amount of work
… it depends on how complex the op is going to be
… very hard to keep them consistent
… need to factor things out and generate common prose
Zoltan: we should refactor things out and reuse whenever possible
… now I think you see the big picture
… this will still be pretty manual process, so need to see what can be factored out, we should do automation exploration
Chai: if the doc is in transient state or inconsistent it will be hard for others to add new things
<dom> [overtime, we can also add CI jobs to enforce consistency - I've done that in a number of cases in WebRTC]
Zoltan: once we get these PRs in them can borrow updated conventions
Chai: optional visibility with <details> would be nice
… original concern was it should be easy for editors to add new stuff
dom: I have experiences with specs that add consistency checks as CI jobs once we know what we expect as input and what as output
… Zoltan is willing to do the manual work now, let's try to get that done as soon as possible to not block the rest of the work
… once we have that base established we look into automation opportunities
Zoltan: if we hide sections, is it better to hide algorithm, validation etc.
dom: parameter hiding sounds good, it is the most boring part
Zoltan: need to check if we can make the whole box disappear and auto-hide it
… I got the feedback, we'll look at it next time with an updated PR
Zoltan: I will ping you on an updated PR with visual enhancements and ping you all
Zoltan: PR #365 is ready and welcomes more reviews!
<ghurlbot> Pull Request 365 Add the constant() method steps. (zolkis)
<chai> i'll take a look
anssik: thanks Chai!