Meeting minutes
WG Charter update
anssik: WG Charter update and next steps from W3C Staff Dom
Dom: first, sorry this has taken longer than I had initially hoped
… by next week Wed-Thu the draft Charter for the WG which has been tweaked should go by the W3C AC review
… reps from all W3C Members
… they have provide feedback and vote
… most importantly that is an opportunity for the reps to comment if they have change proposals, in most cases the changes are around the scope of the charter
… charter delineates IPR commitments members do while joining the group
Web Machine Learning Working Group Charter
Dom: also privacy and accessibility perspective reviewed
… 4 weeks review time for all W3C Members
… also part of this process, demonstrating there's broad support for starting standardization
… we expect 5% or more of W3C Membership to express support, that is 20-22 distinct W3C Members
… it is really important you get your W3C Advisory Committee reps sent a supportive review of the charter
… and encourage your colleagues in others organizations to also get their AC reps pay attention to the review and support the work
… I will be also working contacting various companies who have expressed interest in this space, ML is pretty exciting topic so many people should be paying attention
Dom: after 4 weeks AC review, if there has been no so-called Format Objections, and we get clear signals of support the charter gets approved in a few days and the WG gets started end of March to early April
… if Formal Objections are filed, then resolving them is an involved process
… to sum this up, if things go smoothly we should be able launch end of March early April
… when we're a WG, you are asked to join the WG with your W3C Member affiliation
… there's a path to become an Invited Experts for W3C non-Members
… difference CG vs. WG, you'll get W3C Staff contact for the WG to help with W3C Process, best practices from W3C groups, consistent with other W3C efforts
… all the time, once the group has gathered enough members, we start more formal steps, such as First Public Working Draft publication with Royalty-Free licensing commitments
TAG review feedback
anssik: Discuss key TAG review issues per GH feedback and activity
… note GH label change from "tag" to "tag-tracker"
All GH issues with [tag-tracker] label
anssik: Let's discuss those first that have received comments.
[tag-tracker] NamedOutput mechanism clarification
NamedOutput mechanism clarification #140
anssik: Ningxin says, basically, the NamedOutputs is just used to index an Output by string-based name.
anssik: specific text to add to the spec to clarify?
Dom: horizontal review is increasingly more important when advancing to WG, one of those groups is W3C Technical Arch Group that reviews APIs for architectural aspects
… Privacy Interest Group (PING) is another such horizontal review group, others are Accessibility review, Security review, and Internationalization review, not expecting much I18N or A11Y review
… Privacy is likely more interested in this work and has substantial feedback
… "w3cbot" is a helper that keeps track of this horizontal review and makes sure the feedback is appropriately addressed
… "w3cbot" will help demonstrate wide review feedback has acted upon in a proper manner
[tag-tracker] String enum for activations
String enum for activations #138
Chai: AFAIK, the feedback is to create a separate enum for activations used elsewhere in the API, the issue in this is that in recurrent networks e.g. GRU different activations may be used
… not all can be used in RNNs, so more appropriate to have a blanket enum for all activations, because alternative solution needs a runtime check
… then the API would need to reject that, so preference would be to define an API in such a manner it does not fail easily in common cases
… in this sense, having a specific enum for activations prevents that, i.e. if a new version adds new activations we can just add an additional value to the enum
Chai: we could have a QA section for this spec and park these issues these?
https://
<dom> https://
<dom> https://
[tag-tracker] Constructor or builder pattern for model building?
Constructor or builder pattern for model building? #136
Chai: factory is better if you'd have multiple model builders in the future
… you don't want to expose a constructible type, but have a factory method, .createXXX rather than new FoobarXXX()
… eager mode would require different builders
… so the API is probably better stick with the factory method
Dom: I don't know of many Web APIs that use factory for object construction, re future-proofing the API, I'm wondering how this envisioned on the web where we don't deprecate APIs and APIs can evolve over time, overloading constructors, hiding.
… The reason for TAG response is that factory is not a common pattern in Web APIs
Chai: that is interesting, I'm coming from OS API versioning point of view and design patterns in that context
… in OS platform sense, unless we're really certain there's no other way to construct an object, we'd prefer to have an abstract way to create an object
Dom: this is usual design pattern in other context, the message the TAG sends here is consistency
<dom> https://
<dom> https://
[tag-tracker] getNeuralNetworkContext() and createModelBuilder() params
getNeuralNetworkContext() and createModelBuilder() params #135
anssik: Chai makes a point about the context vs. the model builder
Chai: this seems to be a question from TAG, asking whether these two methods have the right parametrization
… from the conceptual point of view, we want to have two objects constructed by the implementer of this interface
… one is the context object that holds the global state, e.g. NPU or GPU device
… another object is the model builder that holds transient state specific to the topology constructed
… that's the difference between these two things
… the response explains why we need both
Chai: the question is perhaps not specific enough?
Dom: maybe have a call with Sangwhan so this can be synchronously discussed (timezone issue)
[tag-tracker] Training in the batch normalization section
Training in the batch normalization section #134
Discussed in the catch-all TAG review issue: https://
https://
[tag-tracker] issues without comments
All GH issues with [tag-tracker] label and no comments yet
anssik: any questions re TAG feedback?
Explainer feedback
anssik: I can take a look, other volunteers welcome.
Dom: +1 to make this use case driven
… I'll be off next week, otherwise happy to help
Privacy IG feedback and the Security and Privacy self-review
anssik: Wanted to discuss the early W3C Privacy Interest Group (PING) feedback and update PR #132 accordingly
anssik: I'd like to update PR #132 with changes from PING, if any
anssik: PING feedback 1: "What do you think would be appropriate to prevent, deter or minimise sites from misusing or abusing the capabilities of this API? (Note: This is not a problem unique to this API, and perhaps solutions discovered here could help fix problems in JavaScript, WebGL, etc.)"
anssik: PING feedback 3: "Is the API restricted to first-party contexts? Or do third-party frames have access? (The answer to 2.13 of the Self-Review: Security and Privacy Questionnaire (above) suggests they do, and that you are exploring the potential of a policy-controlled feature approach.) Is there any reason not to simply restrict to first party context? (i.e. what are the likely use cases you envision that would require
third-party frames to have access to the API?)"
RafaelCintron: I'm supportive of top-level doc needing to grant access to iframes
… PING feedback 1 hard to answer, because many of these powerful APIs on the platform already let do the same things
anssik: PING feedback 2: "A related question - suppose the API was enabling machine learning use cases involving mouse movements (an example of behavioural biometrics), what are your thoughts about user awareness/consent and mitigations for abuse?"
anssik: ran out of time, PING feedback 4-7 deferred to future call