Meeting minutes
Agenda
Scribe
Cristiano and Daniel
Sebastian: agenda is available on the wiki page
… all materials can be found in wot repository under the PRESENTATION folder
What's new
Sebastian: not major changes
… a lot of minor editorial changes
… about really new features: new operations types
… these types are used to query actions
… they were required by advancements in the profile spec
… new operation types: queryaction, cancelaction, and queryallactions
… alongside this direction we also have a new proposal for handling query actions without this new operation
… need further discussion
… TD signature will not be include in the TD spec but we are going to publish a W3C note
McCool: the signature solution is an alternative of JSON-LD signature
Sebastian: can you give us the latest about TD signature?
TD signature
McCool: we need a signature algorithm but the right place to discuss this is in the IETF
… it fills a gap between jws and ejs
… reference community JOSE community
… we can discuss further on October 28
… canonicalization should be finalized before tackling signatures.
Sebastian: any questions?
… ok let's move on
TD 1.1 vs 2.0
Sebastian: the original intention was to be backward compatibile with TD 1.0
… TD processor based on TD 1.0 shall also work with TD 1.1 versions
… i.e. it can use the TD to interact with the WebThing
… many of the new features are actually backward compatibile
… however some very useful new features would break backward compatibility. Example: forms optional for affordances
… the issue was spawn from issue #878
… in #878 we have an example
Issue 878
<kaz> Describing initial connection #878
sebastian shows the example where websocket information is duplicated in each affordance
Sebastian: base element is not sufficient
… modbus has similar requirements
… global definition of protocol parameters make sense if these information is always the same
… that led to the decision of making forms optional
Kaz: maybe we can ask Takenaka representative on the open day about his feedback on designing TDs for integrating modbus and other protocols.
Ege: I am not sure about making forms optional
… validation becomes hard
… almost impossible
… what happen with the op keyword?
Ege: does it mean that the top level connection should be supported by all the affordances?
… keep in mind that we have the danger of using subprotocol definition as a shortcut
… to not have interoperable definitions
McCool: however if is well-known subprotocol is fine
… we not allow subprotocol that are not defined in our documents
… we just need a criteria for what is a reasonable subprotocol
Sebastian: ws is dangerous, there's even coap over websocket
McCool: we need to review a reasonable set of subprotocol
Ege: in webthings has it's own payload format
… there's a link between affordance and payload data
Sebastian: complicated, what if is compressed?
Ege: you need to decode anyways
Cristiano: we don't care about the payload structure
Cristiano: form definitions? like we have done with security?
Ege: I would say it is safer
Sebastian: new terms? or re-use form?
McCool: good to follow the same pattern
… we had some issues with round tripping
… but we solved for securityDefinitions
Sebastian: a new term?
McCool: no, just extend form
… we can define a simple pre-processor that can convert TD 2.0 and TD 1.0
Sebastian: what about operation type?
… initialize connection there's no operation type
McCool: defaults does not really help here
Daniel: we need to skip 1.1 and go directly to 2.0 because we can't solve 878
… but this is not an argument to skip 1.1
… this is minor
Cristiano: I agree, if we can solve this in a backward compatible manner
McCool: what if publishing two documents?
… it is allowed by our charter
… I know it is tough work
… can we just list differences with 1.1?
Sebastian: I like the idea
… but do we have the man power?
McCool: we can do it as a note and handle in the next charter
Sebastian: addressing things in 2.0 mean 2 years
McCool: not completely we can go CR immediatly
… three years if we start from scratch
Sebastian: if both documents are really close to each other could lower the adoption of 1.1
McCool: do we need 1.1? i.e. do we need to be backward compatible?
Kaz: Given we just have two months till the end of the charter. Even if we can extend it I'm really concerned that we can't reach the Recommendation stage in time
… I'd like to skip features if those keep us out of schedule. Issue 878 contains many sub-issues like how to deal with websockets
… what should we close during this charter period?
… we can't do too much because of the time
… we can always skip and tackle them next year
Sebastian: thank you for your points, I think yes we have the option to skip those
… in Siemens we have no problem regarding backward compatibility we need new features and we would not support 1.0
… who has the problem to break backwards compatibility
Kaz: What about Takenaka? maybe they have already software agents using 1.0
Kaz: we need to keep their opinion in consideration
Sebastian: yes first we have to ask if their going to implement WoT next version
<Zakim> kaz, you wanted to react to Ege
McCool: the real question is be or not be backward compatible
Kaz: we should care about backward compatibility as much as possible.
Koster: I advocate for semantic versioning: 1.1 should be backward compatible and 2.0 no
Cristiano: true
Cristiano: what about cover webthings.io in this charter?
McCool: what we have now is useful since other people are using it
… webthings.io is a 2.0 application
McCool: I propose to rollback and stick with 1.1
Sebastian: it seems that we have the consensus to keep 1.1 and publish it as soon as possible
… in 1.1 there's the TM concept which is a new achievement
<kaz> kaz: ok
Ege: about the issue discussion I have a couple of slides, should I post them there? or spawn a new issue?
<Ege> The slides I mentioned are here: https://
Kaz: we should really mark the issues to be deferred and the ones related to this charter
Koster: some new features may go under TMs
<sebastian> proposal: the group decided that the TD 1.1 should be backwards compatible and should be realeased as REC asap. A first version of TD 2.0 can be published just after the TD 1.1 was released.
<Ege> https://
Resolution: the group decided that the TD 1.1 should be backwards compatible and should be released as REC asap. A first draft of TD 2.0 should be released asap (begin of next year?) just after the TD 1.1 was released.
<kaz> [10-min break]
Guest
Koster: Mikkel Haggren Brynildsen working for Grundfos
… worked a lot with semantics
<kaz> W3C Patent Policy
Koster: Grundfos has factories in 52 countries
Kaz: Suggest Mikkel to join meetings the next week given he needs to leave now.
MHB: Will try
Collections for TMs
Sebastian: We have a PR almost ready to be merged
… #1207
https://
Sebastian: allows to define composition of TMs
… using links container
… instanceName used to distinguish
… instanceName is optional
… some updates on "how to generate TDs based on TMs"
… another way to generate TDs based on top-level TM is also possible
… all interactions are taken
… to avoid name collision renaming is applied using instanceName that was provided
Sebastian: I would appreciate to get feedback on this PR#1207
… we also explored it in the PlugFest
McCool: w.r.t. examples, using "href": "./"
… not sure if this legal
McCool: fully qualified url might be better
Ege: relative urls mean under this TD
McCool: defined somewhere?
Ege: don't think so
<Zakim> Ege, you wanted to react to McCool
Sebastian: Good point, will address the comment
Cristiano: Some concern as Michael
… moreover, 2 different methods with generating TDs
… which method to choose
Sebastian: Recommended method each TM the TD
… however, in case of low power devices
… no need to download additional TMs
… everything is in one place
<McCool> (btw, mag 6.1 earthquake near Tokyo today...)
Cristiano: TD implements only *bigger* TM
… what about recursions?
Sebastian: Recursion is allowed
… can have more re-directions
Reduce TD redundant information
Cristiano: WebThings may be complex software agents
… description hard to read and to maintain
… this can become a problem
… shortened TDs are quicker to load, parse, read..
… Why do TDs get larger?
… - security definitions
… - different protocols
… - different flavors of API endpoint
… - protocol redundancy (e.g., WebSocket)
… - complex data schema
… w.r.t. security definitions
… one security for the entire TD
McCool: Pr#945 has implications for signing
… compatibility issue
<kaz> WIP: Simplified inline security definitions #945
Cristiano: Yes, may be future work
McCool: we should have named forms, security etc .. in a consistent way
… comboSchema might be also beneficial
Cristiano: w.r.t different protocols
… every form is multiplied for all protocols
… not sure if we can do anything about it
<Zakim> McCool, you wanted to react to cris
Cristiano: w.r.t different flavors of same endpoint
… e.g., node-wot creates TD with each network interface
… "simple" counter example creates 798 lines of TD
Cristiano: w.r.t protocol redundancy
… e.g., Modbus using endianes
… no need to be repeated on every form
Cristiano: w.r.t complex data schema
… TD schema has 1280 lines
<Zakim> McCool, you wanted to react to McCool
McCool: contentType could indicate schema
Cristiano: cases were this does not work
McCool: omission of schema is an exception
Cristiano: was thinking about pointing to external data schema
McCool: maybe something for 2.0
Cristiano: new keyword usable in 1.1
Kaz: Proposals make sense to improve maintainability
… anyhow, should think "who" generates TDs
… manual TD generation?
… shortened version.. may create issues for implementations/validations
Cristiano: Agree
… TMs can help to generate TDs
… in the context of WebThings .. I encountered issues
… any yes,. shortened version may cause issues w.r.t. validation
Ege: w.r.t. reference external schemas
… JSON schema is working on it
… openAPI allows it
… linking to URL on the web causes issues with $ref
… not like fetching
… otherwise we need to define fetching mechanism our-self
<Zakim> McCool, you wanted to react to Ege
McCool: using JSON schema mechanism?
Cristiano: Not sure why the chose not to do it
Ege: problems with incompatibilities .. I think
Cristiano: Yes, not easy to solve
Sebastian: comment about schema definitions
… limited to additional responses
… should make schema definitions usable by other terms also
Cristiano: Agree
Sebastian: Cristiano, suggest to create dedicated issues
Cristiano: Will do
Binding Templates
Ege: I will talk about restructuring work
… not fully complete yet
… prev. draft contained big chapters
… payload was partly about platform standards, mediaTypes
… we also had redundant information from TD
… all this information in different places
… if I am interested in CoAP only I need to pick parts out of different chapters
… idea was to categorize bindings and externalize the content
… externalize means separate document
… each binding in its own document
… "now" we have a short intro in main binding templates document
… in section "Protocols" each protocol points to own document
… this was a big change.. and I ask for feedback
<Ege> https://
Kaz: This big change at once is not very beneficial for review
… however we agreed to merge
… might want to ask external reviewers also
… also "changes" section might help
Ege: Yes, I am working on it
Kaz: Naive question to M. Koster. Did you review all changes?
Koster: Yes, think so. Might go over the document again.
… to me it is ready to go
… we just need to be used to new structure
… no change on format
… basically just restructuring
… with multiple documents
Kaz: Good to hear
… we might still want to re-introduce "old" content. let's continue the discussion during the Editors' calls as well.
Sebastian: I agree with M. Koster
… should look into next steps
… working on new protocols
… OPCUA, BACnet, ...
… new structure helps with that regard
Sebastian: Kaz mentioned DID registry in recent TD call
… need to agree on process
… what do I need to do IF I want to add a new binding
Ege: suggest to postpone this discussion, have some slides about registry
Cristiano: My open PR needs to wait before being merged
Ege: Yes, we need to wait for review
Kaz: We need discussion with other people, like ECHONET
… ECHONET people had issues when preparing for PlugFest
Kaz: current draft is more guideline
… we still need specification document / description
… that's why we need collaborate discussions
Ege: I see
Kaz: Content has been improved but also changed a lot
… almost a second version
Sebastian: I understand the concerns
… looks new
… but the document was not maintained very much the last 1.5 year
… we talked about how to improve
… now we have a bigger change.. but it is a result of the discussion over the last months
Kaz: I do not say improvements are bad
… we need to ask for a new review
… Overview section needs to be improved. That's rather procedural issues but we need to start over the ordinary procedure.
McCool: Simple procedural thing
… 6 months extension
… need to check the timeline?
… isn't a W3C note only
Koster: Agree
… binding templates should not be a specification at all
Ege: Some parts of the document should be eliminated
… or moved to TD
<Ege> https://
Ege: some examples are good.. but there are some orphans.. not sure were it should go
Ege: One other aspect is registration issue
… Submission procedure
… defines what needs to be provided
<Ege> https://
Ege: how to deal with further binding submissions
… e.g., node-wot has more bindings
… firestore, mbus, ...
… netconf
… how can we bring this work for bindings to WoT / W3C
… see issue, https://
… DID has formal way
Kaz: I am not pushing for DID procedure
<McCool> (sorry, I have to drop early, I have another meeting I have to do to...)
Kaz: but IF we want to have a registry, .. DID procedure is something we can look at
Ege: I agree, we should review DID process
Kaz: Should read W3C process document also..
Sebastian: How did DID come to the process?
<Ege> https://
Sebastian: registry *can* be managed by W3C
… we can also use IANA if that works for us
Ege: I think IANA does not work for us
Kaz: depends on what we want to do
… so we should clarify what we want to do first and then contact Wendy, Philippe, .. but I'd suggest we discuss that not today but in the near future given the time for today.
Sebastian: We have a meeting with DID Oct 28
… can talk with them
<Ege> https://
Sebastian: suggest to continue discussion..
Wrap-up
Sebastian: Open day next Monday
Sebastian: talk from Takenaka
… using WoT in their system
… after presentation we have PlugFest report
<kaz> [adjourned]