Meeting minutes
Previous Minutes
<kaz> Sep-5
Daniel: Last meeting was the one before TPAC
… during TPAC, we at least got one slot to discuss the move to formal note which was approved
… the minutes themselves look good to me
… any objections to making them public?
Cristiano: Just one note: Aren't the names changed before publishing?
Daniel: That's done by kaz manually afterwards
… apart from that any more issues, concerns?
… if not, I would ask kaz to mark them as final
Minutes are approved
Summary of the TPAC Meetings
Daniel: We had some discussions before the TPAC regarding a switch of the document type
… we now switch to a Note including Normative portions during the next charter, which enables us to use normative statements (SHOULD, MUST, ...)
Kaz: Please note that there is no difference for publishing the WoT Scripting API as a WG Note from the viewpoint of the W3C Process.
… we can just use normative statements in some places, which is not endorsed by W3C as a whole
… Anyway, I don't think there is any difference from the W3C Process viewpoint. As recorded within the TPAC minutes, I'll talk with PLH about this idea, but you all are also encouraged to visit the www.w3.org/TR area to see similar cases of normative group Notes. If we need to explicitly mention we're planning to generate a group Notes containing normative portions within our new Charter, that might be going to cause additional discussions during the AC reviews.
Daniel: If we don't need to make specific changes, it is fine for me
… if it causes any issues we need to revisit this topic
… I will go through the Process document once more, and will see the examples of normative Notes at the TR area.
WoT Profile
<dape> https://
Daniel: There were some discussions before TPAC, but I am not sure if everyone is aware of this week's Profile Plugfest
… Michael Lagally sent an email today
<cris_> ack ?
Daniel: Plugfest starts tomorrow, node-wot and Scripting API are not supporting the Profile yet (completely)
Cristiano: According to the email, the Plugfest starts next week
Kaz: The date in the wiki is wrong
… mentioned before that this week would be difficult to organize, therefore the Plugfest got postponed
… date in the Wiki needs to be updated
… even having the Plugfest next week is at risk in my opinion, as we are not yet prepared
<cris_> +1
Daniel: I agree, we are not well prepared
… not sure if I can implement the profile in node-wot until next week
… feel free to contribute
… started a PR for node-wot, adding profile-specific operation types
… currently those op types are limited to the profile, but they might come to the TD specification as well
Kaz: We need to have a plan for the Plugfest and set the requirements
… the Plugfest should only collect the results
<Mizushima> +1 kaz
Kaz: should be discussed in main call and Plugfest call
Daniel: Requirements should come from the Profile taskforce
Cristiano: I agree
Daniel: As kaz said, otherwise Plugfest is at risk
… I think Luca Barbato was also working or at least exploring a Profile implementation
… this was it for the quick updates
PRs
Daniel: Some PRs are stalled, there was activity in the ones by Cristiano and Jan
PR #423
<kaz> PR 423 - Remove eventHandler
Daniel: There were some remaining questions regarding "void" in the context of the payload
Cristiano: To avoid confusions, I used the word "empty" instead of "void"
Daniel: The only thing I noticed was the formatting of the empty term
Cristiano: I will fix it
Zoltan: I think we should add more examples and specify something in the algorithms
… also we should refer to existing specifications
… or to protocol bindings
Cristiano: Unfortunately, I think there is no section in any of the protocol bindings
Daniel: Protocol bindings are sadly not entirely ready yet, although Ege indicated that they might be ready soon
Cristiano: I heard something similar, we should discuss with Ege that algorithms should be added
Kaz: Binding Templates are not describing anything concrete yet, as Daniel mentioned, we need a drastic content update
… we need to keep in mind the overall structure of the specifications
… probably, this is out of scope for the current charter and should be addressed in the next charter period
Daniel: Discussing with Ege, since he also responded here, sounds like a good idea
<zkis> https://
Zoltan: I opened an issue and added a comment with my points
Daniel: I'll change the formatting of the "empty" term from code style to italics
… then we can move on, right?
Zoltan: I think we could even merge
Cristiano: Would be fine to merge
Daniel: He got two approvals already, so let's move forward
PR is merged
Ege has joined the call in the meantime
dp informs Ege about the current state of the discussion -- an empty payload might have different semantics depending on the protocol that is being used
ek: We are not using algorithms defined in the Binding Templates yet, but defining an empty payload sounds good
… it is a special case where no data is present, we haven't specified it yet
… I will take it to the Binding Templates
Daniel: maybe you can add a link to issue #430, Ege
PR #405
<kaz> PR 405 - feat!: add new Discovery Web IDL definitions
Zoltan: I noticed that the url has become mandatory, this should be moved and discussed in a separate PR
Daniel: I was wondering if we should have something like "auto" as well
Zoltan: Could be specified in the algorithms
Zoltan: We could also include auto configuration in the discovery case without uri parameter
Cristiano: This PR is introducing an AsyncIterable now, right?
jr: Correct
Zoltan: The uri parameter change should be moved to a different PR to make faster progress with this PR
… we also need to take into account the security aspects from the Discovery specification
… the algorithm changes look fine, we could have a look at other specifications as homework
Issues
WoT Issue #1049
Daniel: Please have a look at this proposal for new points for the next charter
… I suppose as before, there will be a section regarding other deliverables in the charter
… in the last charter, there was no mentioning of discovery, this is definitely something that needs to be included in the next charter
<dape> https://
Daniel: please have a look regarding wording etc.
Kaz: As I mentioned before, we need to clarify the relationship among the WoT specs and the whole structure of the related specs.
… we need a discussion in the main call that goes beyond just mentioning discovery in the Scripting API
Cristiano: Is this the right place to mention the provisioning API?
Daniel: I think that it makes sense, but in the end it will probably just become one paragraph
… we should discuss this main call
… feel free to add comments
[adjourned]