Meeting minutes
previous minutes
<kaz> Jan-26
Sebastian: we discussed about the eventing
… I added the corrisponding issue to today's agenda
… after we had a look to our publication plans, PRs and finally issues
McCool: about removing md5 we had a resolution in security for the removal
Sebastian: ok, daniel should have already done that
… in conclusion we announced the initial design of the Bacnet binding
McCool: is there a modbus implementation?
Sebastian: yes it is
Kaz: I talked with Takenaka representatives about BACnet, he's ok to provide additional information. However, he's preference to work with the WoT Japanese CG first and then report back to us
Sebastian: is it ok to mention this in the issue?
Kaz: yeah, it is already recorded in these minutes
Sebastian: anything else?
… ok minutes approved
Publication plans
Sebastian: just remember that the idea is to have feature freeze soon
… are you okey with postpone feature freeze for next week?
… most specification parts are very stable
… remeber that feature freeze is just about blocking new features
McCool: we might define a filter to what should be accepted as changes
… a label could be helpful
wide review call
Sebastian: I started the process for the publication checklist
… we are on good path
McCool: you are missing the exact transition point
Sebastian: ok
Sebastian: questionares about privacy and security need feedback
McCool: btw in the main call we agreed that this task is assigned to security task force
Sebastian: maybe you check what other groups are doing
… someone sent an email
McCool: not sure if this is the right way of doing it
Sebastian: what about putting the answers in a issue?
McCool: probably, to be discussed in the security task force
PRs
PR 1360
McCool: not ready yet
… in the related issue there's a list of things that need to be addressed
… the PR should be finalized for the next week
Sebastian: issue 1363 might be solved in the same pr as well
McCool: since we have one already in flight we can
Sebastian: we can wait one more week to cover also these changes
McCool: ok, but the changes are informative and do not effect test fests
PR 1366
Sebastian: there were missing definitions
Cristiano: there might be some conflicts with another PR
Sebastian: I see
… my preference is to merge this one and ask Ege for resolving the conflicts in the another PR 1368
… ok?
… no objections, merged
PR 1367
Sebastian: clean up PR, very trivial, it removes a document that was not matained
… no objections merged
PR 1369
Sebastian: this PR removes an old image
… any objection for merging it?
PR 1370
Sebastian: same as the other PR it removes an old file
… any objections?
… merged
PR 1371
Sebastian: it removing old images of the TD model
… any objections for merging?
… ok merged
PR 1376
Sebastian: it is about MD5 example, it simple removes the example
… it is still allowed, but not quite recommended
McCool: also the ontology should be fixed in the TD 2.0 ontology
Sebastian: removing from the enum should cause validation problems
Daniel: true
McCool: I would leave in the json-schema but removing from the examples
… I would just deprecate MD5
Daniel: the document is saying that we just allow strings
McCool: I ok for limiting to those three values
… I changed my mind, string can be used for extensions
… so I would remove enum
Daniel: ok
Issues
issue 1323
<kaz> Issue 1323 - Missing event/notification affordance or operation
Sebastian: it will be discussed more in depth tomorrow in the architecture call
<presents the contents of the issue>
McCool: dataResponse field is fine
… the real question is if we need the information also on the listener side
… I wonder if the contract can be expressed with a link
McCool: it is also too tight with webhooks
… I'm ok having the api just on one side
Sebastian: ok, I'm bulding a TD uisng Lagally proposal
… but you can express the same using the action
McCool: note the op notify goes in the consumer side
Sebastian: yeah but the consumer is also producer (it creates the TD)
Cristiano: not sure if there is the practical use case for searching about things that are waiting for events
… usually is the opposite
<dape> +1
Cristiano: in close systems this can happen but since they are close you can manually connect the software components without advertising it on the td
Kaz: I agree that the details should be discussed later on the arch call. I'm not too much convinced too.
… we might need cover this functionality but not in the TD
Issue 1343
Sebastian: the new context files needs to be hosted under w3c namespace
Kaz: ok, I'll work on this issue
… would you like to keep the existing reference to the 1.0 version?
Sebastian: yes
issue 1364
Sebastian: the request is to extend the scope of schemaDefinitions for all the schemas in the TDs
… we can make the TD shorter
… any comments?
Daniel: it would affect the implementation, it makes it more complex
… doable
McCool: the fact is that you're doing it anyway for addtionalExpectedResponses
… it is the same approach for security defintions
… I wonder about ontology definition
… we should accept strings for schemas
… I all for this
… just keep in mind the ontology problem
Cristiano: there might be problems with properties
McCool: we could add a new optional field
… with the schema embeded
jan: what about having a json pointer? similar to tm:ref
… and maybe define override mechanisms
Sebastian: yeah, then there's the question of reusing the same feature from json schema
Daniel: I would definitely not limit this feature only for actions or events.
… just a reminder that property extends DataSchema therefore it is used as a validation json schema
… this would not longer be the case
McCool: the json pointer thing is complicated and is incompatible with how we treat security definitions
… on the other hand I think we could handle it just for actions or events
Sebastian: Maybe we can simply post pone this for TD 2.0
… I'm concerned about side-effects
Issue 1352
Sebastian: the webhook example is missing the subprotocol keyword
… it should mention "webhook"
… the problem is that webhook is not a well defined protocol
… what should we do?
… one idea could be to introduce a set of string values to indicate a non standard webhook implementation
Cristiano: I would not using special patterns for indicating the webhook protocol
McCool: I agree, we might introduce the subprotocol once we have expirence and verified that we can describe the implementations using additional keywords
issue 1363
Sebastian: we already discussed this
McCool: I did one part of it
… I can conver it for next week
issue 1325
Sebastian: the TD spec should strictly specify that keyword are presented and validated as case sensitive
… I would simply add a sentence in the very beginning
… asserting that all the terms defined are case-sensitive
McCool: is there anything that is not case-sensitive?
feature freeze
Sebastian: I'm not seeing any new feature request besides eventing
<sebastian> proposal: group decides to freeze the discussed feature set for the TD 1.1. There is an exception for the eventing discussion which will be decided next week.
Cristiano: does the new PR about thing link have some implications?
McCool: no
RESOLUTION: group decides to freeze the discussed feature set for the TD 1.1. There is an exception for the eventing discussion which will be decided next week.
WoT binding
Sebastian: we already discussed it in the intro
… let's close the section
<kaz> [adjourned]