Meeting minutes
<sebastian> brb
Kaz: We should focus on charter topics right now.
… basic consensus in 30 minutes is fine
Ege: Will increase charter slot, 75-120 min
… PRs will help to settle charter discussions
Minutes
<EK walks over the minutes>
Ege: Minutes look good to me (apart from dp vs dape names)
Kaz: fixed Mizushima capitalization also
… fixed Jans name also
… looks good -> minutes approved
Binding Templates
PR 224
Ege: agreed to merge this PR last week
… merging now (since I forgot)
PR 228
Ege: used to be lots of examples
… now there is a single example only
… makes it more concise and easier to read
Daniel: +1
Kaz: We should clarify our goals/content before generating PR
Kaz: Our goal like "clarify what binding templates means" .. and therefore we move X to Y
… I don't see the plan as a whole
Sebastian: What do you mean?
Kaz: entire group should clarify the goal
Ege: goal of binding templates is clearly specified.. also in Arch document
Kaz: In Arch and TD document there is explanation but I think we need to add explanation to bindings document too
Ege: Arch gives overall idea
Kaz: I ask you to concentrate on bindings document
Sebastian: We are doing that right now
Kaz: M. Koster has concerns too
Koster: Yes, I think there are a number of things we need to look at
… having discussion would be useful
… a matter of understanding the high level
… at the moment we are resolving questions
… but are doing that at low level
… I think we should clarify the high level questions
… 3 sub-sections
… 3 sub specifications
… a few items like that we need to examine
… we don't speak how payload binding works
… we haven't designed sub-protocols
… don't need to be final.. but we need to understand the way it works to move forward
… need to agree on process... needs to be written down
… should mention also registry sections
… these are just some points I see
… main issue I see is to be normative ... but we should try to be normative on the result
Kaz: I totally agree
… would like to think about high level structure again
<Mizushima> +1 mjk
Kaz: discuss what is normative/informative
… could use additional diagrams
Ege: 3 comments
… 1. Please provide information to Agenda/schedule
… 2. w.r.t. high level structure.. not sure what that means
… Arch spec explains at high level
… please create issue about high level structure
… I think we have high level structure
… 3. mechanism of TDs should not be part of binding
Sebastian: I agree with Ege
… I think everything expected from binding document is in the document
… a while ago we decided to split the document
… to also allow specifying it from other SDO
… we talked about that in the past... no alternative proposal was given
… not sure why we want to go back to point zero again
… I still don't understand the issues
… I was listening to developers and they seemed to be fine
Kaz: I am afraid, my point was misunderstood
… I do not want to go back the 3 years old version
… I suggest to think about structure for next charter
… the bigger question is: binding document does not include the mechanisms how it works
… some basic description are in TD and Arch
… binding spec is separate document but should also include all the mechanism
… we should clarify mechanisms in this document as well
… that kind of structure needs to be clarified before moving to PRs
Koster: a lot of work is done to specify artifacts
… what I see is missing is good understanding on the process
… we should establish clear consensus what a binding is and how it works
… we need to think about interfaces
… we have good ideas about technology... but we miss how the puzzle pieces go together
Luca: I am new to WoT
… startet WoT with implementing it
… Arch document is too big and broad
… felt lost
… TD document was easy to grasp
… binding was good enough for our needs
… the problem is more on that Arch document doesn't get you loose
… my experience was fairly positive
… I don't think binding document is the problem
… e.g., discovery document reading helped to understand Arch document
… we should improve cross-linking
… tutorials might help
… TLDR might help also
<mjk> Luca, are you creating a new protocol binding?
Ege: w.r.t. to cross linking, no overlapping content?
Luca: one way or the other is not the problem..
… when reading Arch document I did not find the right links to more specific documents
… implementations helps to understand (and we have good implementations)
Sebastian: Question to Kaz
… is there any problem to publish current draft as note?
Kaz: we did not publish the last 3 years
… I do not see the need to publish now
… now we should think about the content that should go into the document
Sebastian: Would you have a problem publishing it, since we didn't publish it for a so long time?
Kaz: Today, I would not agree with such a resolution
… we can agree on "aiming to do X and Y"
… 1. structure
… next, actual content
Cristiano: Couple of comments
… it seems it gets a blocker.. we need to solve that
… core mechanisms touch different aspects
… we moved some mechanisms to Arch ... now we want to have them back
… i think it is better to improve description in other documents
… and link them properly
Cristiano: next charter binding might become normative... which would be a different discussion
… we should not stop work now
Kaz: I asked editors which feature should be described where
… we failed doing so
… we need to re-think the whole WoT structure/family again
… IF we are okay with informative binding in next charter this is fine
… we need to clarify what is normative
Kaz: Question to Luca B.
… which version of Arch and binding spec were you looking at
Luca: I read Arch document 2 years ago
… binding document I kept reading also recently
… first time Modbus did not exist
Koster: I agree that we can do update
… I think we should talk about next charter
… we need to have a clear idea
… like Luca's comment about cross linking
… w.r.t. binding we have different audience
… how binding works..
… and people making a *new* binding
… creating new binding needs a lot more information
Ege: For next charter we are going with sub-specifications
… for now at least
… the proposal says binding document should be normative
… we describe 3 registry sections (for stable and experimental)
… if we don't update binding publication soon we just have a very old document to show to other SDOs
… it does not give a good impression
… hence I think publishing update is very important, also for next charter
Koster: That explains a lot of things
… we need a few things to address the issues I mentioned before
… how bindings works could be linked to Arch document
… or a short description with a proper link
Ege: new PRs bring moved sections back from Temporary sub-sections
Koster: feel like getting more description there
mizu: recently, I talked about Binding Templates with JP stakeholders
… and they mentioned they didn't refer to the Binding Templates document
… because they didn't understand the content itself
… but they could handle TD just based on the TD spec
Ege: TD can't work without the binding capability
… impossible to avoid using forms element
… we mainly use HTTP but still need to use forms for HTTP interaction too
… everybody should understand the mechanism
… maybe some additional description needed somewhere
<dape> Kaz: My point is similar to Mizusima-san
<dape> ... bigger question is that TD and Arch have similar/identical descriptions
<dape> ... still we need better description in binding document
<dape> ... should improve TD/Arch as well
<dape> ... Ege, I appreciate your work and see that the document is getting better
<dape> ... still, we need to clarify overall structure
Ege: ok, tx
… need to see potential impact to the other WoT specs as well, e.g., Architecture and TD
<dape> Kaz: External developers have difficulties at the moment
<dape> ... since they use HTTP mostly
<dape> ... new protocols might cause more problems
<dape> ... need to describe the mechanisms more explicitly
Sebastian: interesting feedback from Mizushima-san
… which version of the specs were you referring to?
… old published version? or ED?
mizu: they were referring to the ED of the Binding Templates
Sebastian: ok
… can you ask them to raise concrete issues on GitHub?
Kaz: as you know, the WoT-JP CG is planning to have a Dev Meetup to clarify the issues
Sebastian: we've already created a dedicated issue on how to update the Binding Templates Note
Kaz: we're already in an extended Charter
… and preparing for the next Charter by the end of May
… so I'm asking to add concrete deadline to each of the topic within Issue 232
… and the goal to see when our update ends
Sebastian: but we can publish a WG Note whenever we want. right?
Kaz: right
… but that's basically during our ordinary Charter period
… we're already out of time, we didn't publish any updated Notes for 3 years, and we're now on our extended period for new Charter preparation
… so we should be even more careful
Sebastian: would it be OK for Ege and Koster to talk about the plan?
Kaz: yes
<Ege> w3c/
Kaz: if they can talk about what to be described by which spec by when, please do so
… we can get the feedback next Wednesday
Koster: I'm happy to have that discussion
Kaz: tx!
PRs
<Ege> w3c/
Ege: contentType to be used
… (shows preview)
Ege: feedback was we had too many examples
… so picked up one of them
… (shows diff as well)
Ege: any objections to merge it?
(none)
merged
Ege: (shows the "Files changed" and diff)
section "4.1.1 Introduction to Protocol Binding Templates" and later
Ege: added description on Payload Binding Templates
… there is some description on subprotocols
… which are still in Appendix
… but need to describe that as well
… any objections?
Koster: high level description still missing
… we should get benefit from the description on how to write abstract TDs
Ege: right
… we can have some more discussion around that
Ege: merged
Koster: I have a short list :)
Ege: Jan's PR on Json Schema for CoAP binding
… (shows "Files changed")
… we've started to work on JSON Schema for all the target protocols
Koster: would be good
Ege: any objections?
(none)
merged
Ege: then MQTT now
… fix issues on MQTT
… and then define JSON Schema
… any objections?
(none)
merged
Ege: fixing prefixs
Ege: (shows diff)
Ege: any objections?
(none)
merged
Ege: JSON Schema for HTTP
… should make it mandatory or not?
Jan: Would including the TD context URL as an alternative be an option here?
Ege: right
Luca: what if a value expected to be some kind of graphics?
Ege: good point
Ege: can provide basic protocol @context like modbus
… but maybe we should encourage this kind of TD
… (showing example 7)
<JKRhb> Is there a registry of well-known of JSON-LD prefixes?
Luca: should not handle all the complexity of JSON Schema for TD
Ege: JSON parser can be used instead
Koster: for interoperability we should define some prefix
Ege: would talk within Siemens about that
… anyway, I'll contact Koster for the discussion points from today's call
… meanwhile please give comments to Issue 232
Sebastian: also would be good to have concrete PRs
… and clarify the publication schedule too
Kaz: right
<sebastian> https://
<sebastian> :-)
[adjourned]