Meeting minutes
Calendars
Kaz: as PLH mentioned within his message to the Chairs, we're encouraged to use the group Calendar to manage the WG calls. However, we need to confirm the calendar entries because it seems some of the entries are strange. Also we have similar information on the Wiki and the Marketing page as well. So should clarify how to deal with them too.
Minutes
<kaz> Jan-25
Sebastian: we need to remove details for the TD and Binding Templates charters
… they need to go to another document
Kaz: I will add some of my sentences to the binding minutes
Sebastian: any objections?
Sebastian: minutes are approved
Charter Items
PR 1063
<kaz> wot PR 1063 - TD Work Items
Ege: I will do the detail removal once the PR is merged
Ege: I will add some new items such as virtual things and what is also in my comment above
Sebastian: we can merge now and remove the details later on
Sebastian: any objections to merge this?
Kaz: merging is fine, but we should not through the details away. So we should find where to put the details
Cristiano: how should we review this?
Sebastian: we will evaluate everything once they are here
Sebastian: there will be a separate repo where the charter will live
<kaz> kaz: will create a separate repo for further discussion, and try to move the remaining PRs to that repo. To be honest, it would be easier to merge all the remaining PRs right away, and move the updated HTML to that separate repo, though :)
PR 1065
<kaz> wot PR 1065 - WG Charter - Binding Templates
Sebastian: we have a similar PR for the binding templates
Sebastian: we can merge it like the TD PR. We need to summarize the work items and move details somewhere else
Sebastian: there are merge conflicts
Ege: I can resolve and merge it if there are no complaints
Sebastian: I hear no complaints
Thing Description
TD version management
Sebastian: you must have seen that the root url has td 1.1 version now
<kaz> i|w need to|scribenick: Ege|
Sebastian: so you need to know the URL in advance
… our bibliography also self links
<kaz> version guide
Kaz: we have version management guide, and this is the proper behavior.
… you can also see all the specifications via the "History" link within the spec
… we should understand that first, then agree on a policy (and apply the policy all the WoT specs equally), and make sure to use dated URLs for reference purposes.
Ege: It is trivial to add a link, we can agree on a policy
Kaz: also 1.0 is an obsolete document once 1.1 rec is published
Ege: we can add (obsolete) in the text
Daniel: I find it wrong that a CR version is replacing a REC
… once we reach 1.1 REC, this is fine but now it is wrong
<kaz> s/we need to remove details/scribenick: Ege/
Daniel: this is probably the same in arch document
Kaz: Right. On the other hand, please remember that CR is already a stable document. So it's reasonable to use the latest CR draft for the canonical URL instead of the old REC from the W3C Process viewpoint.
PR 1684
PR 1684
w3c/
Sebastian: this PR fixes as much as possible until TD 2.0
Cristiano: also this fixes some CI pipeline issues
Sebastian: you can see that it only affects the semantics
Sebastian: so we can merge it
<kaz> PR 1712 - Add table numbers and captions using new respec option
PR 1712
w3c/
Ege: I get errors again, the captions are the same
… cris can you have a look ?
Cristiano: yes I can
Sebastian: let's see next week
PR 1732
<kaz> PR 1732 - Minor follow-up syntax alignments/fixes
Sebastian: thank you daniel for the fixes
PR 1737
PR 1737 - Add explanation about observeproperty relationship
Ege: This is just to add a statement that there is no guarantees
Sebastian: so a consumer does not necessarily get a notification of property changes
Sebastian: we can stop the TD part for now, Ege will do the binding templates now
<sebastian> bye
<cris_> bye!
Binding templates
PR 228
Ege: moving orphaned sections back into the main body
Ege: today I tackled content-type section
Japanese vendor's feedback
Kaz: it needs several improvements especially the core document.
… you wanted to know their availability to join this call
… I asked them
… they are very interested in the discussion, but they are concerned about the current mechanism
… 1. hosting a developer meeting up and evaluate together the current document
… ... 2. do a Japanese meetup, collect feedback and then report back
Ege: good news
… we could start with the developer meetup
… after that we can start welcome them our calls
… would it work?
Kaz: Mizushima-san is already working on a Japanese meetup
… it will be held in February
… so I would recommend to first wait and get an initial feedback
… later we can organize a second global meetup
Mizushima: I don't have a date yet
Kaz: true
Ege: after the 15th ?
… so that we can have a deadline to get a better document
Kaz: not sure
Ege: ok then it's asap
… but that's a great news
PR 228
<kaz> PR 228 - Temporary Section Reorg - Part 2: Payloads
Ege: This PR fits well in the discussion about the improvements
Ege: improved the section structure
<ege shows changes about content-types>
Ege: any questions?
Daniel: quick note: last example have contentType in the wrong place
Ege: yeah, I can quickly fix it
Cristiano: maybe there are too many examples about different content types?
Ege: it is nice to have multiple examples
Daniel: I think I see the point, maybe it is enough to a list of different content-types without ripeting the form
Ege: I see, that make sense
Cristiano: agree
Ege: any other opinion ?
… I would still have single json example with a list of possible content-types
PR 224
<kaz> PR 224 - Add initial version of feedback survey
Ege: it would be helpful to gather feedback from devs
… would it relevant for the Japanese meetup?
Kaz: at the moment I am not sure
… in any case we should discuss what should be described by the core document a priori and then we can ask feedback.
… current draft includes important pieces but it is kind of a cheatsheet
… we need more explanatory text
… the survey would be too tough for external people
… even if the survey per se is a good idea.
… so we should think about this kind of questions as part of the possible Developer Meetup for Binding Templates
Ege: can we do both ? events + survey?
Kaz: we can ask participants in the online meetup to provide further feedback in a survey
Ege: about the PR are you ok for merginng?
… ok, then I'll merge it but without sending it
issue 227
<kaz> Issue 227 - JSON Schema for CoAP Vocabulary
Ege: we need a json schema for each protocol binding
… Jan are you going to work with CoAP?
Jan: yes, I will
Issue 230
<kaz> Issue 230 - JSON Schema for MQTT Vocabulary
Ege: is somebody free to create a jsonschema for mqtt?
Cristiano: I can
Issue 229
<kaz> Issue 229 - JSON Schema for HTTP Binding Terms
Ege: tricky because is coming from an external vocabulary
Ege: how should we treat RDF data, in the json schema?
Cristiano: you mean how to use keyword that are not in the RDF ontology?
Ege: no, more about if we should use all the keywords or just the ones useful for us
Daniel: reduce it to a sanity check
… do not list all the precise values for HTTP
Kaz: we can talk with some semantic web experts
… from the other w3c groups
Ege: we can, but about what?
Kaz: if they know more about this kind of vocabulary
Ege: we can do it
Kaz: we should refer to external vocabulary as much as possible
… that's why I'm suggesting to ask
Ege: it is not vocabulary related by it is more about the json schema related to the thing description
Kaz: json schema is used for validating the vocabulary in this context ?
Ege: not really, it is more about validating our data
Kaz: would we want to refer to specific ontology terms?
… if jsonschema is complicated, semantic experts can help us
Ege: they would probably recommend SHACL validation
… it would be too much
… we need a simpler mechanism with json schema
Kaz: what do you mean by validation ?
Ege: coming from thing description
Kaz: should explain how a TD that contains protocol binding keywords should be validated
Ege: ok, any other points?
Kaz: are we asking external developers to write protocol specific binding validation them self?
Ege: correct,
Kaz: but it is a good amount of work
Ege: but we can collaborate
Kaz: still it is a bit too much
… the core document should focus more on the mechanism of the bindings
Ege: schema is helpful
Kaz: the reason I'm concerned it is also testability
… how are we going to test also this additional requirement?
… manually or automatically
Ege: maybe this discussion should be held another time
Kaz: I have another point of view
… we should actually discuss it right now,
… going forward on this direction would not be right
Ege: I don't understand why we should not doing it on this charter
Kaz: why do we need add new description to the main body?
… we should finalize the document
Ege: this is to improve the readability of the core document
<kaz> [adjourned]