– DRAFT –
WoT-WG - TD-TF

Meeting minutes

<kaz> Apr-13

<Ege> https://github.com/w3c/wot-thing-description/issues/1467 to be added

<kaz> (minutes approved)

Agenda

<kaz> agenda for today

Binding Templates

PR 156

MQTT Binding: https://github.com/w3c/wot-binding-templates/pull/156

Cristiano: PR is ready for review

<kaz> (postponed till the next call)

PR 157

CoAP improvement: https://github.com/w3c/wot-binding-templates/pull/157

Ege: Merged

PR 151

Modbus Binding: https://github.com/w3c/wot-binding-templates/pull/151

Ege: Merged

PR 140 and Issue 139

Discussion on text binding: https://github.com/w3c/wot-binding-templates/pull/140 and XML Binding: https://github.com/w3c/wot-binding-templates/issues/139

Cristiano: Concept needed, but maybe suggested text is going to far?

Ege: Agrees

Kaz: Can we really tell intention of the data if the format is text?

Cristiano: Could interpret text as number if parseable as such, otherwise it's difficult

Kaz: That's my point. For example, ECHOENT Lite Web API uses their Device Description which is similar to WoT Thing Description but their old specs used other text format or even binary format. So we should be careful about which type of payload data to be covered by the Binding Templates.

Cristiano: This is only about payload formats

mccool: also there is a possibility HTTP header says it's text but the actual content can be JSON

(some more discussion)

Kaz: we should clarify our scope for the ver. 1.1 specs including TD and Binding Templates

Issue 143

<Ege> https://github.com/w3c/wot-binding-templates/issues/143 Issue 143 - "Protocol Binding" vs. "Binding Template"

Kaz: Protocol Binding is a technology and Binding Template is a specification for that purpose
… that should be explained by the Architecture spec
… but if that's not clear enough, we should improve the Architecture spec
… also the Binding Template Note should be confomant to the Architecture spec

Ege: right

Ege's comment

Kaz: before closing the issue itself, we should check with Ben as well

Issue 125

Issue 125 - Payload based protocols

Koster: should be in the binding

Ege: my concern is you could get various possible subprotocols

Cristiano: agree
… would prefer something more generic
… better to have a common way to handle this issue
… currently it's just a subprotocol but actually scalable

Kaz: yeah, we should clarify our scope around subprotocols as well

Thing Description

TAG review

<kaz> w3ctag/design-reviews Issue 715 - Web of Things (WoT) Thing Description 1.1: TAG and Security Review

McCool: There were an assertion in the architecture that we only support protocols with URI schemes
… but we adjusted it that we can also support protocols like MQTT or OPC-UA

Ege: Actually, the assertion was that the URI schemes need to be registered at IANA
… and that got removed

McCool: The reason for the origial assertion was to make it web-like

<Ege> https://w3c.github.io/wot-thing-description/#protocol-bindings

McCool: and allowing all mechanisms from the web
… but every IP address is a URI, right?

Ege: There are agreements on URI schemes in certain communities, for example in the case of MQTT
… and these schemes do not have to necessarily be registered at IANA anymore

McCool: Technologies like Bluetooth or ZWave do not have URI schemes, but they can easily mapped to protocols with schemes

Ege: We are focussing on IP based protocols right now

McCool: We can give the author of the issue the answer that we are focussing on IP based protocols and otherwise use gateway solutions

Kaz: We should ask the author for clarification or invite him to discuss the issue.

McCool: There is an easy distinction: protocols that use IP and protocols that don't
… question about scope
… focus so far has been on IP based protocols
… in theory, if there is a URI scheme for it, we support them, too, but we did not discuss those in length, yet
… ZWave and Bluetooth are not out of scope in general, but are not feasible to support with our current scope

Kaz: We should discuss non-IP based addressing
… we should clarify our criteria for a protocol or technology that be used for WoT

The group discusses the wording for an answer to the issue's author

<McCool> would propose: "the Wot TD is not meant for general web services, but there are often web services associated with IoT systems, such as proxies, shadows, and digitial twins, for which WoT TDs are appropriate"

McCool: I think non-IP protocols are implicitly out of scope of the current spec

Kaz: regarding this GitHub Issue for TAG review itself
... my suggestion is rather simply inviting them to our call like we did for 1.0 specs

McCool: I have had contact with him before, the TD call might be a bit too late for his timezone, we can invite him to the main call

PR 1452

<kaz> wot-thing-description PR 1452 - WIP: fix: allow uri value only for in field of APIKeySecurityScheme

Jan: tried to resolve conflicts but still some problems there

PR 1468

<kaz> PR 1468 - feat(context): use "@type" instead of "rdf:type"

Ege: CI is failing for this PR because the author has not signed the IPR

Kaz: Is it an editorial change?

Ege: The context is changed

Kaz: In general, we should ask people to open issues instead of PRs

McCool: Should we make the author an invited expert?

Kaz: Not needed for this PR alone

Ege: Author is very interested in RDF roundtripping

McCool: Fixes technical issues, which are details but still relevant

Kaz: We can consider the changes editorial changes, but we need to discuss if they really non-normative

McCool: We can ask them to sign the IPR
… problem if the changes turn out to be copyrighted later
… if authors contribute code, then they certainly need to sign the IPR agreement
… easiest way to let them sign the agreement is making them invited expert

Kaz: I would like to first see if the changes are really needed

McCool: Let's suppose it fixes a problem with roundtripping, then it is an important thing to get right
… so I think they could raise an issue and let someone else fix the problem
… an alternative could be to let the author state in their PR that they agree with the IPR policy

Kaz: The person has created three other PRs, therefore we should be stricter
… and tell the person that they should open issues instead

Ege: Christian Glomb knows the author

Daniel: Why don't we simply accept them as an invited expert?

Kaz: In this case we can make them an invited expert, depending on their affiliation
… as they work with Siemens, we might be able to discuss it with Sebastian next week

Ege: I also contacted Christian

Issue 1415

<kaz> Issue 1415 - Definition of 'well-formed'

Ege: I propose closing this issue
… as it has been resolved by PR 1456

Issue 1412

<kaz> Issue 1412 - Languages of service-doc?

Ege: Can be closed as it was fixed by PR 1449

Issue 1375

<kaz> Issue 1375 - i18n review checklist for TD 1.1 REC

Ege: This one can also be closed as there are separate issues for the checklist now

Issue 1384

<kaz> Issue 1384 - A TD should be able to define which Properties are required

Ege: Thomas added the label "Propose closing" himself
… I also think it can be closed

Issue 1462

<kaz> Issue 1462 - Bringing back Cert Security Scheme

Ege: There haven't been implementations for the CertSecurityScheme which is why the scheme is not in the spec
… there is one implementation now, which is why could add it back in

McCool: I think the ship has sailed for adding new stuff to the spec, in TD 2.0 we should rework SecuritySchemes as extensions

Kaz: We are already in an extended Charter period
… we would probably need to mark this feature as "at risk" if we need to revert this.
… so I'd agree with Michael McCool that we should defer this
… I propose to add the "Defer to TD 2.0" label to all the remaining issues by default (and possibly can revisit them later).

Issue 1338

<kaz> Issue 1338 - title must be mandatory for properties, actions and events

Ege: Issue is probably not relevant anymore
… Michael Lagally propose making title mandatory in affordances
… does not actually solve the problem it tries to solve, causes i18n issues

McCool: We are discussing this profiles
… if no title is present, then you could also simply use the affordance key
… similar to mandatory security definitions
… people could also simply provide an empty string, which would cause more issues

Ege: I am closing this issue then

Issue 1324

<kaz> Issue 1324 - Feedback on latest Editor's Draft

Ege: There has been a long discussion in response to the feedback by Ben
… opened a new issue for one aspect of the discussion regarding a missing mapping between DataSchemas like "Subscription" and operations like "subscribeevent"
… we could open the review issue by Ben and continue the discussion in the new one

Daniel: If the discussions in the old issue 1324 have been resolved then we can definitely close it

Kaz: Before we close it we should cheeck with Ben that his points have been addressed

Daniel: On the other hand he could also simply reopen it

McCool: We could mark it as "Propose closing"

Kaz: I agree, then we can continue the discussion next week

Ege: I also agree, I add to the issue that Ben could also close the issue if he thinks his points have been addressed

<kaz> [adjourned]