Meeting minutes
minutes
<kaz> Agenda for today
Ege: you should have seen the minutes
… is there anything that needs to be changed?
… minutes approved
Agenda
Ege: is there any updated on PR 2081 ?
Jan: nothing yet
Ege: next one is Binding registry, there are three PRs active
Ege: we should choose the next Work Item, we need more input
… next we have to work on the initial connection expansion algorith
Sebastian: I joined to let know about the review phase of the OPC UA binding
… the document is not that long, you should review a single chapter 6
… I'm looking forward to hear you feedback
Ege: we can do the discussion today
Ege: is it ok to discuss OPC UA binding today?
Ege: added
OPC UA Binding
<EgeKorka_> Sebastian's message about the OPC UA Binding Document
Sebastian: it should only visible for working group memebers
… please don't share it outside this group
… it is fine to get feedback from github issues
Ege: we are not going to follow the "official" review process of binding
<EgeKorka_> https://
Ege: we can just do basic tests
… for the future we should follow the process described in the link above.
Ege: The document as a initial introduction section
Sebastian: it is something required by the OPC UA foundation
… just a basic explaination of the context
… if you go to chapter 6 you will find TD relevant information
… 4 to 5 page maximum
… previous parts might be removed
Ege: the goal of the document is to describe an OPC-UA server
… hrefs targets will be "nodes" a concept of OPC UA data model
Kaz: technically, Sebastian should forward this document to the W3C Liaison Team mailing list as well given there is an official liaison between OPC and W3C.
… second point we can use this document as an example application for our expected WoT Binding Registry.
… and we can think about how to improve our proposed WoT Binding Registry procedure based on that discussion.
Cristiano: where should be the feedback collected?
Ege: wot binding templates repository issues
… with label opc-ua
Sebastian: the binding is pretty simple, mainly is all about the URL
… and some additional optional keywords that might be used for further explain how to connect and interact with the server
Ege: note that the URL main contain enconded characters
… the document contain information about security defintions
… we should include this information in our process
Ege: the default prefix is uav
Sebastian: as you know it is just an example prefix it can be changed
Sebastian: format is not perfect yet
Ege: then a the bottom there are examples
… I'm interested in the default mapping between op keywords and opc-ua configurations
Sebastian: there is some information in the access level paragraph
… but there is not really a default provided
Ege: is there an equivalent of the HTTP GET method?
Sebastian: good question, I don't really know
… they should have read and write command
… you can use the issues to raise the question
Ege: there should not be so much flexibility
… but it should be good to have it
… checking the current todo list for the new process, we are aligned
… but we are missing this mapping information
… probably we need also a JSON schema to validate the form parts of opc-ua TDs
… anything else should be fine
… there are small things to improve
… but anybody here can help
Ege: you can experiment using off the shelf libraries
… node-wot support it too
Binding Registry
PR 423
Ege: we agreed about the version of a binding should look like
<kaz> Binding PR 423 - Registry versioning requirements
Ege: main thing we agreed is the uniqueness
<sebastian> ok, I have to leave for another meeting. Thanks and bye
Ege: the document must contain a changelog
… and all the previous versions listed as links
Cristiano: do we explain that version should define a concrete ordering scheme?
… or is it implied by previous version links?
Ege: do we version summary document too?
Cristiano: yeah
Cristiano: also they should explain ordering only if it is not already clear
Ege: yes
PR 424
<EgeKorka_> Binding PR 424 - Machine readable documents requirements
Ege: we agreed before quite a while ago.
… we only require json schema
… and really advice to place a json-ld context
… straightforward PR , any remarks?
Future of registry requirements document
<kaz> Binding Issue 421 - Where should the registry live?
Ege: it is in a very good state
… we can turn it into an editor draft
… we should get opionions about issue above
… current TD editor draft contains everything about the binding mechanism
… the binding is going to be just a registry document
… currently we have two options
… use current wot-binding-templates, delete everything and redirect back to TD
… create a new document, keep the old one but create a new red banner
… any proposals? opionions?
Cristiano: ok for proposal 2
Kaz: wot-binding-templates repository was focused on editing the group note
… from my view point it is better to have a different repository to help people understand the differences with the new approach
Luca: ok for proposal 2
… I'm also ok to use the old repo to store current set of bindings (http, coap, etc.)
<janro> +1
Koster: ok for 2
Toumura: ok for 2
Mizushima: 2 works
Ege: ok then we have 100% consensus
<EgeKorka_> proposal: Create a new repository called wot-binding-registry to manage the new registry and use the old repository for managing the individual bindings
<cris> +1
<EgeKorka_> proposal: Create a new repository called wot-binding-templates-registry to manage the new registry and use the old repository for managing the individual bindings
ok good for me now
RESOLUTION: Create a new repository called wot-binding-templates-registry to manage the new registry and use the old repository for managing the individual bindings
[adjourned]