Meeting minutes
Organization
(brainstorming on how to run the TD/Binding TF)
Kaz: We should clarify the assignment and responsibility of the TD TF lead
Cistiano: 1+ for clear responsibilities
Mizushima: +1 kaz's opinions
Minutes
approved
Charter
PR 92
PR 92 - Protocol Bindings Option 1 - Default protocol bindings in binding documents
<Ege> w3c/
Ege: Ben mentioned a Profile issue (285)
… specify the default protocol binding in the protocol and payload binding documents?
Kaz: are we really sure about this kind of detailed mechanism at the moment?
… I don't think so, and this should be discussed during the Charter period later
Ege: yeah, these PRs have "Detailed Work Items" label
Cristiano: agree we should discuss the details during the Charter period
… not really sure about the document names proposed here
"Protocol Binding" -> "Protocol Vocabulary" "Payload Binding" -> "Payload Serialization" "Combination Binding" -> "Platform Mapping"
Cristiano: would be good to keep this open
… and discuss this separately from the Charter discussion
Ege: yeah
… (adds comments to PR 93)
Koster: we don't really need to resolve this
… need to wait on the discussion on binding in general
… we probably need some placeholder for the discussion what is needed for the default
Kaz: +1
Kaz: as I suggested last week, this kind of technical details issue/PR should be moved to the technical repos like wot-thing-description or wot-binding-templates
Ege: right
… but this issue is related to both of them
Kaz: in that case, simply "wot" instead
Dev Meeting
Ege: have generated two slide sets, one for TD and another for Architecture
Kaz: we should work on the Dev Meeting mechanism one by one
… first of all, we'll work on the TD testing next Wednesday on March 29. Right?
Ege: yes
Kaz: that should be also clarified
… then we should clarify the Goal of the event
… then Motivation mentioning the requirements of the W3C Process
… i.e., checking the implementability of the spec
… also interoperability of the features
… that's why need 2 or more implementations
… then what to be described by whom for the slide set?
Cristiano: Can work on links back to the spec sections
Ege: and still need help for TD examples
Kaz: it seems there are 20 or so features at risk
… and there are 9 people here
… so can ask people to take 2 for each
Daniel: the question might be that we ourselves are not really sure about all the assertions
Ege: I've added clarifications to each assertion as "Resolution"
Kaz: in that case, you can add a concrete example TD to some of the assertions
… and ask people to work on the others
CR: Does implementation report mention what implements a given assertion
Ege: not really.. we need to dig into
PR 1783
PR 1783 - Remove at risk items in the sotd section
Ege: removes CR transition text
Kaz: at some point we need to remove at-risk features
… However, at the moment I would keep it because we're holding the Dev Meetup to see the latest implementation situation of the at-risk features listed here.
Ege: Okay, let's postpone it after meetup
Binding Templates
PR 262
<kaz> w3c/
Ege: adds figure and explanation text
… added quotes to figures
… we use SVG now also
… another PNG was deleted and changed to SVG
… reviews from Cris and Daniel
Ege: no objections -> merging
PR 263
PR 263 - Specifying terms influenced by different bindings
Ege: Integrated feedback
… adds a small table what is required a new binding template
<kaz> Preview - 4.1.1 Introduction to Protocol Binding Templates
Ege: how to validate URI is handled in another issue/PR
… the same table was added for Payload Binding template as well
Ege: Not hearing any objections -> merging
PR 46, CoAP Ontology
-> PR 246 - Generate CoAP vocabulary from RDF
Jan: Cristiano suggest to change folder structure
Klaus: for CoAP ontology ... not really an ontology
… on the contrary for HTTP
… vocabulary should "sit" in same folder than binding
Ege: sort of agree
… problem I see is with other SDOs ... whether they want to host it in the same folder
Cristiano: different use-cases
… structure not very clear ... ontology in protocol folder
… should be described
… I like consistency also
Kaz: General comment/question
… protocols defined by external SDOs .. should be handled by them
… ontology also
… if this is difficult.. than we can think about hosting it
… anyway, should be joint work
Ege: IETF writes CoAP ontology .. could they host it
Klaus: IETF does not do work.. only individuals
… within IETF it could be picked up as work item
… we do not use CoAP RDF
… specific to Web of things
… question where such an ontology should be described
… having the CoAP document in the current location seems right to me
Ege: More a question to what to say to future collaboration
… I think we do not have any problem hosting/maintaining the ontology
Kaz: not a technical issue of putting a file
… but we should work together with other SDOs collaboratively
<kaz> Liaison
Kaz: maybe we should talk with PLH about this
Ege: Question about protocols where we do not have the expertise
Kaz: We need to think about the whole structure
… which entity to be linked to which external resources
… which entity to be created by us
Ege: I think we can document this in issue 216
… w.r.t PR 246 I think we can merge the content
… are there technical blockers ?
Klaus: I posted list of open issues
… anyhow, suggest to merge first and work on it in a follow-up
Ege: Makes sense
Cristiano: W.r.t. some issues we need to discuss further
Jan: I also posted 2 more comments
… we could handle in follow-up PR
… anyhow, I am fine with merging
… last question: Should most recent commit w.r.t. structure be reverted?
Ege: No, fine as is
… can do a follow-up change
Kaz: I am okay with merging
… initial starting point
… on the other hand we need to think about how to integrate related protocols
… for a bigger mash-up system
Ege: Yes, a bigger WG goal
Kaz: We should think about it in the next charter period
Ege: Merging PR
Klaus: Thanks Jan for the great work!
PR 266
PR 266 - Reorganize intro and section 4
Ege: Reorganized intro and section 4
… incorporated also feedback from Cristiano
Ege: I will not merging it now
… agree with Kaz, it looks nicer
<kaz> Preview - 4. Binding Template Mechanisms
Ege: need to resolve the conflicts, also need to update the introduction as well.
PR 268
<dape> -> PR 268 - Add TD Consumption step
Ege: We need more algorithmic work
… things happening in Consumer
… understanding href
… 1. detect the protocol
… 2. choose correct protocol stack
… 3. validate forms of TD
… 4. Start communication
Luca: Reference to JSON schema, could we relax it ?
… w.r.t. "you may use"
Ege: I see
Luca: Information extracted from URI, the scheme
… I don't think we can do that with the JSON schema
… need to parse the URI
… or relative URI (if base URI is used)
Luca: Do we just want to use the scheme ?
Ege: Like other keyword ?
Luca: Yes, like a protocol keyword
… would be even more clear
Luca: Maybe we can add note where to find dataSchema
Cristiano: +1 Luca
… not very clear what generic consumer needs to do
… step 1 for example does not need to be done every time
… dataSchema and contentType could be linked to the actual definition
… in Scripting we wait for sections to link back to Binding document
Kaz: Probably it is good to have discussion on concrete algorithm about how to deal with the TD on the Consumer side. However, I'm not sure if Binding TF is the right place to have this discussion. Maybe we need broader discussion on TD in general or even a separate implementation guideline of primer.
Ege: Correct, temporary place at the moment and close to TD
Kaz: Could use "detailed behavior" label or so to identify the issue better
Thing Description
PR 1776
PR 1776 - Make response contentType required in JSON Schema, regenerate TM schema
Ege: there was an oversight
… contentType was required
… Jan fixed that
… looks good -> merging
PR 1772
PR 1772 - Add table numbers and captions using new respec option v.2
Ege: adds numbers to tables
… Cris made respec PR
… and was released already
… this way the PR is complete
… table have link and number
… great work Cris
Ege: No objections -> merging
PR 1784
PR 1784 - Update readme links to different versions
Ege: fixed link pointing to wrong version
Kaz: We should use dated URI every time. So this change is good.
Ege: merging
PR 1762
PR 1762 - fix: ignore ReSpec warnings
Ege: adds lint ignore for respec
… no objections -> we can merge
[adjourned]