Meeting minutes
<dape> s/Charter: /Agenda:
Daniel: approving previous minutes
<dape> July-18
Daniel: no objection, minutes can be made public
cancellations in August
Daniel: cannot make 15 Aug
Cristiano: can't make it on 15 and 29, perhaps 5 Sep, too
Cristiano: Sep 5 works
Zoltan: let's try to do it biweekly in August, on 8 and 22
<Mizushima> +1
Daniel: will send out cancellations
next charter
Daniel: we can move the Scripting API to the W3C Note Track
Daniel: this is a different process, we need to study it, etc
Kaz: did not mean to re-publish the doc, just provide the latest description of the W3C process, with a possible option to adhere to it
… and to discuss in the group and W3C what is the best way to move it forward
Daniel: ok - the next charter starts in February, until then we need to clarify these things
Daniel: we need to discuss the charter topics as well
Kaz: the document is already a Note and adding the Note Track was that the CG's have right to publish Notes. On the other hand, WG's could not publish Notes that have normative features.
… there are 3 possible options, and we need to discuss which is best for Scripting
Kaz: options: informative Note, formal Note, RC
… an RC document is a deliverable of the whole W3C, whereas a Note is a deliverable of the WG
Daniel: this is not a minor update since we need to change the API as well
… we need to discuss it in the WG
issues
issue 417
<dape> https://
<kaz> s/417 Issue 417 - emitPropertyChange does not take low-level event apis into account/
Zoltan: there seems to be a misunderstanding in the usage of the API
Kaz: I suggest discussing with Ege with concrete usage scenario
Zoltan: we could support an informative value with notifications, but we cannot guarantee that value
Zoltan: also, the value may be long or complex (e.g. stream) - we don't pass values with notifications
issue 408
<dape> https://
CA explains why we don't need an EventHandler
Daniel: we have optional data when emitting events, but why we don't have data with change notifications
Cristiano: because the data is defined locally when emitting events, and read with notifications
Zoltan: it's a broad and deep change, and needs more considerations and checks
Jan: will also check this from implementation pov
Cristiano: I can work on a PR
Daniel: we need to check the related spec sections for possible simplifications
issue 409
<dape> Issue 409 - Harmonize the exposing process
Zoltan: explained the comment in the issue
Cristiano: yes, that is an alternative way
… they differ in the moment the checks are done for a valid exposed Thing
Kaz: we should focus on the use cases and continue offline
Daniel: meeting adjourned