Meeting minutes
anssik: Welcome to the future, err, 2025!
… and welcome to our new participants Michal Grabowski and Michał Pierzchała from CallStack, a software engineering consultancy
… your feedback as an ISV is very important at this stage of development
WebML Working Group Charter 2025-2027 draft out
Repository: w3c/machine-learning-charter
anssik: thank you for your review and suggestions
… all suggestions have been integrated into the draft
anssik: HTML diff helps review delta to the current charter, also see the commits for more context
anssik: two open issues are deferred from this WG charter update cycle
… - new incubations #36 will be consideration in a future after adequately incubated, possibly mid-cycle
<gb> Issue 36 Task-based APIs and Prompt API (by anssiko) [deferred]
anssik: - on-device training #27 did not receive any feedback that'd suggest we should bring this feature in scope for the WG
<gb> Issue 27 On-device training (by anssiko) [deferred]
anssik: an advance notice has been sent to the W3C Advisory Committee and all W3C group chairs to give a heads up
Advance notice: Advance notice: Work in progress on Web Machine Learning Working Group Charter
anssik: we expect to initiate the formal W3C AC review in February 2025
Device selection abstractions
Repository: webmachinelearning/webnn
anssik: Zoltan has composed an explainer (thanks!) that summarized the group's prior discussions and proposes a "Minimum Viable Solution" to be used as the basis for spec changes
… PR #784
<gb> Pull Request 784 Add device selection explainer (by zolkis)
anssik: this explainer is ready to merge
… any concern in merging the explainer now?
anssik: the next step is to translate the following changes into a spec PR:
… - Remove MLDeviceType as explicit context option.
… - Update MLContext so that it becomes device agnostic, or default/generic context. Allow supporting multiple devices with one context.
… - Add algorithmic steps or notes to implementations on how to map power preference to devices.
<jsbell> LGTM!
Zoltan: one question is will we ever reveal what devices are bound to the context, also want to assess Mike's proposal (3rd in the explainer)
anssik: the rest of the changes need some more discussion and land in a separate PR
… thank you Zoltan for advancing with this important feature!
<ningxin> +1 to merge
WebNN Operator Update Wave 3
anssik: Dwayne has worked on a spec patch for the Wave3 op set in a branch, much thanks!
… this is many lines of code to translate into pseudo code algorithms and explicitly specify each step in spec language
… WDYT Dwayne, what works best for you?
Dwayne: I'd like to add examples still, I don't think we need to split the PR, this is incremental, so not so much new concepts except the quantization ones
<ningxin> webmachinelearning/
<gb> Pull Request 805 Opset wave3 (by fdwr)
Josh: binary and logical ops could go in a smaller PR
<dwayner> webmachinelearning/
anssik: on the implementation front, I believe the Wave3 op set implementation in Chromium is now complete after notEqual operator landed this week
https://
Dwayne: correct
Josh: interested looking at the PR
<ningxin> I'll take a look
Updated coding conventions and style tweaks
anssik: issue #783 and PR #797
<gb> Pull Request 797 Editorial: Various style and wording tweaks (by inexorabletash)
<gb> Issue 783 Proposed style/wording tweaks (by inexorabletash) [editorial]
anssik: as our spec grows in size and complexity, it is important we have coding conventions in place and well maintained
anssik: this makes editing the spec a nicer experience, and also helps us onboarding new contributors
… Josh put up a PR that updates coding conventions as well as the lint tool
… the PR also applies these to the spec to make it more concise, linkable, less error prone to edit
… thank you Josh!
… it is important to build on existing infrastructure and write the spec in terms of WebIDL, Infra, HTML reusing established conventions
… PR #797 welcomes review
Josh: all editorial, every change is because I noticed something that can be improved, the PR chains all these changes I spotted
… some discussion with Ningxin what style convention to use for shapes, I wanted more discussion on this
Dwayne: I'll review this
Create new objects with a Realm
anssik: issue #793
<gb> Issue 793 Create new objects with a Realm (by a-sully) [conventions]
anssik: the realm concept represents a global environment in which a script is run
HTML spec > Realms and their counterparts
anssik: we want to apply realm concept in this spec consistently and properly
… Josh flagged one area in the spec we can improve on:
… when creating a new object from "in parallel" steps we need to specify the realm
Josh: any time there are steps running in another timeline or "in parallel" and JS object is created an explicit realm must be specified, not all web specs do this yet
… unclear if we need to do this in more places, as a homework will get in touch with experts in this area
… for "in parallel" need to capture the realm and pass to the algorithm
Josh: the impact of getting wrong realm is minor, pretty important if dealing with x-window communication though, no huge stress for WebNN
Define equality for non-trivial data type
anssik: issue #792
<gb> Issue 792 Define equality for non-trivial data types (by a-sully) [conventions]
anssik: continuing the theme, comparing equality, two cases:
… - MLOperandDescriptor dictionaries, these are ordered maps
… - lists e.g. « "a", "b", "c" », there's 100+ of these
… Infra spec does not define equality for maps or lists
… should we define general map and list equality and upstream to Infra?
Josh: probably define by ourselves and then open upstream bugs
Disallow operations on scalar tensors that are no-ops
anssik: issue #794
<gb> Issue 794 Disallow operations on scalar tensors that are no-ops (by reillyeon) [operator specific]
anssik: Reilly explains there are a number of operators, such as transpose() and reshape()
… also there are operators like gather() which expect indices but a scalar doesn't have indices
… initial proposal to disallow these cases due to added complexity to implementations
… in a follow up discussion, it was clarified reshape is not actually no-op since it changes the shape
… the refined proposal seems to be "go through each case where we allow a rank of N and clarify whether 0 is a valid value of N"
Dwayne: I thought the next step is to look at the ops and see what makes sense, in a math sense it makes sense to include scalars, but with implementation difficulty need to find a balance
… reshape does work with scalars
… next step is to make a list of ops and see which can support scalars and which don't
Josh: we are persuaded by arguments that frameworks will handle these
Specify destroy() methods and behavior around context loss and error reporting
anssik: issue #477 and PR #744
<gb> MERGED Pull Request 744 Specify destroy() methods and behavior around context loss and error reporting (by inexorabletash)
<gb> CLOSED Issue 477 API lacks handling for async ML device errors on the context (by bbernhar) [bug] [question]
anssik: this issue resolved itself and PR landed before the meeting, thank you Josh, Bryan, Mingming, Reilly, Dwayne, Ningxin!
… with this PR, MLContext gains a destroy() method and a lost promise attribute. MLGraph similarly gains a destroy() attribute.
… modifies also "has built" tests on MLGraphBuilder methods to be a "can built" test
… Josh what should the group know about this change, what were the most tricky bits?
Josh: subtleties, initially when crafting the PR tried to carefully follow the implementation
… there's some divergence in the spec text and implementation, possible edge cases that'd benefit from tests
… secondly, to make things easier on the spec side, it is written using "run this and abort if"
… Chromium implementation has frontend and backend objects with a connection, if connection breaks frontend runs some behavior but not all implementation may use a similar impl architecture
… feedback from other implementers would be very useful
Allow NaN and infinite values for float attributes
anssik: issue #800
<gb> Issue 800 Allow NaN and infinite values for float attributes (by lisa0314) [bug] [question]
anssik: a case where the implementation and spec disagreed:
"The current blink IDL uses float alpha while spec defines as double alpha. I suppose both have issues and it should be defined as unrestricted double which supports both infinite and NaN."
anssik: per issue discussion there are no strong use cases to allow Infinite and NaN values for float parameters still in spec
… Dwayne posted a snippet of IDL for these dictionaries in the issue
… the proposal by Dwayne is to not change the spec and Ningxin agrees
… Ningxin opened a Chromium issues to align the implementation with the spec:
https://
anssik: can we close this issue?
<ningxin> +1 to close
<jsbell> also +1 to close (and always happy to revisit)
<Mike_W> +1 to close
Incubations
Dedicated CG meetings and WG-CG collaboration work mode
anssik: I'd like to complement the bi-weekly WG meetings with dedicated meetings for the Community Group (CG) incubations i.e. task-specific APIs and Prompt API (aka built-in AI APIs)
anssik: this would allow participants to joint one or both, based on their preferences and schedules
… I'd suggest the WebML CG to meet regularly (bi-weekly, monthly?) and hold F2F meetings together with the WebML WG to efficiently pool resources
… since we're a community split across geos, it'd be beneficial to have this CG meeting at a time that works for the most active CG participants
… I've asked Etienne from Google to help facilitate the CG meetings and provide updates on key issues to the WG to ensure the entire community stays abreast of incubation progress, even if you can't join the dedicated CG meetings, you'll stay informed
… per CG charter, a public summary or minutes will be provided
… for async collaboration with the CG, we continue as usual, GH repos are open to contributions
… Etienne, what meeting times would work for Googlers involved with this work?
Etienne: a few folks in Tokyo, EST, PST
… twice a month might be good cadence in the beginning
RafaelCintron: I'm a bit biased, because I'd be joining both, I'm OK with two meeting series
Etienne: Tuesday morning PST is not working for me
MikeM: propose 9-12 EST timeslots