Meeting minutes
<Ege> https://
Minutes
<Ege> https://
(link to the slides above added)
minutes approved
test related issues
PR 1758
mm: "at risk" won't make it into the final PR anyway
<Ege> w3c/
PR 1758 PR 1758 - Updating at risk assertions in the main body merged
kaz: we have already published a list of at risk features
mm: this will be marked as an update
kaz: we can't put that information in the editors draft
mm: we could remove it from the main draft
kaz: it's just a memorandum for us
… we need to publish a new CR to update this informaton
mm: we should delete the at-risk feature list from the draft
<Ege> w3c/
ege: created an issue for this
ege: implementers please look at this as a source of at-risk items
High-level description for new charter
mm: recommend against a major redesign, suggest incremental improvement
… for example, streaming
mm: are there issues for all the work items?
mm: for the charter we don't need a detailed list of work items
… we want to fix the major problems with small improvements
cris: I agree, there are some issues with forms and operations need work
… maybe some things will need a lot of redesign
… we shouldn't limit ourselves artificially
… may want breaking changes
luca: agree, we may need to remove some items
… we should first remove what isn't working and then discuss what can be added
cris: for the charter we don't need to be specific
kaz: the title of this issue should be "high level scope description" for this discussion
… then regarding the content of this issue, we should think about use cases to further extend industry deployment
mm: there should be a use case for each feature
<Mizushima> +1 kaz
mm: user stories also
<cris_> +1
ege: some things are not use case motivated
cris: we can't always rely on use cases
<kaz> mjk: we have use cases but still have bugs
<kaz> ... need general use cases on how to use TD
ege: this is the question; are there large issues
mjk: agree, there are bugs in addition to use cases
kaz: sometimes the use cases are difficult to write down. However, we still need use case description with user-side story for the required features.
… for example, TD without forms still needs a use case to inform how to implement it
mm: we can use the form "as a", "I would like to", "in order to achieve"
ege: we need to differentiate between new features and improvements
<cris_> +1 for user stories
cris: high level scope requires some more imagination, but we still need user stories
… agree that we need to create issues for these user stories and use cases
ege: agree that there should be a document with some template
kaz: there are even user stories driving bug fixes
mk: agree, user perspective is part of both bug fixes and new features
naming discussion
ege: what do we call the different mechanisms involved in a binding?
… tried to map out different concepts
… core binding template document, protocol and payload bindings, profile documents, TD instances, and TM models
kaz: we need Ben's input to this discussion
<Ege> w3c/
ege: wil invite Ben Francis and schedule a time slot in the meeting
… in the meantime, please review and comment on this issue
publication schedule
ege: how many weeks are needed for the review by the WoT WG?
kaz: 2 weeks
ege: update to schedule
… add 2 week review period for binding templates after 5 weeks
technical discussions
json schemas for bindings
PR 237 - Add JSON Schema for HTTP
… there is no technical reason to have a separate document, just size
ege: remove URI from the binding since it's in the context
luca: how will JSON schema validate this case?
ege: it uses a string pattern
luca: do we reject use of non-htv namespace?
cris: these is a limitation of JSON schema and variable keys
<Zakim> cris_, you wanted to react to kaz
luca: another option is to add a JSON-LD validation step
luca: would like to provide a way to prevent conforming instances from breaking things
ege: the consensus was that we should direct implementations to use the official namespace
dape: there could be a check on the external context
kaz: in 237 and 239 we have bigger question than binding templates, that also impacts TD itself
ege: agree, for example the geolocation issue is similar
kaz: maybe we could put the binding core back into the main TD document
luca: moving the description to the TD document makes sense and could be normative
… if the registry is structured properly
cris: agree, it's a potential direction
ege: will create an issue for discussion
cris: is not a bad idea to merge protocol binding templates into td
… but I am not sure if we can technically merge it a recomandation into another charter wise
mk: +1 only downside is the readability
<mjk_> mjk: +1, no technical reason except size
<mjk_> luca: we could refactor into TM as a separate document to reduce the TD size
luca: if the problem is the length of the main document, we can refactor it by moving TM out
mk: I think protocol binding can also be a sort of mapping between TM and TDs
ege: intresting
mk: we haven't yet document how to map abstract data structures into a payload structure
ege: we still need work there
<mjk_> mjk: the payload binding may need TM references
ege: but protocols should be easy
PR 250
<kaz> PR 250 - Mention that the HTTP binding mirrors the TD spec HTTP Binding
ege: just mirroring TD spec
… any objections?
dape: how you link the TD doc? are you point to the editor draft?
ege: yes, you are right I need to update it
… ok now merging
… also merging PR 237
PR 241
<kaz> PR 241 - Refactor render script
ege: Jan worked on coap ontology and the render script
… changing the render script
… I'd prefer to merge it cause is a dependency of other PRs
jan: improves readability
cris: +1
PR 246
<kaz> PR 246 - Generate CoAP vocabulary from RDF
ege: this is a good update, but we need to wait for klaus review
jan: it is a starting point
… we can regenerate the document
… ontology still needs improvements and discussion about its future direction
ege: the index.html does not really contain substantial changes
… it is more about tooling update
… I also asked to add Jan as editor
+1
… if klaus approves the PR we can merge it without group meeting
… any other opinions?
… ok thank you Jan
PR 249
ege: I've just created it
… it addresses an old temporary section about subprotocols
… we need to discuss if we need it
… the definition is a little bit fuzzy
… but I didn't update it a simply move it
… I also added one sentence, explaning that can be explained in the binding document.
… i.e. longpolling should be explained in the http binding
cris: I would create an issue to keep track of this new requirement for binding templates documents
ege: yes
… coap is probably already mention it
mk: are we calling coap observe a subprotocol?
ege: yes
mk: the meaning of subprotocol is ambiguous
… for websockets it defines application protocols
… we should bound what a subprotocol can or cannot specify
ege: for websockets is kind of straightforward
… but for other protocols it gets weird because they have their semantics
mk: exactly, http has less degrees of freedom
… which should figured out if the subprotocol meaning can be bounded
ege: websocket is like tpc in that sense
luca: I would remove subprotocol
… the form operation is not reach enough
… I would remove it and just rely on the protocol binding
luca: if it is just not just a tag
… you need more vocabulary terms
kaz: we could remove sub-protocol but need to describe the websocket use in different platforms
cris: we should see if we can extend the form description to provide these descriptions
… there is also a transport protocol question like MQTT over websockets
… we need a way to describe these also
ege: this applies to RPC protocols in general
<cris__> ege: back to PR
<cris__> ... should we merge it?
<cris__> ... I would like so
ege: back to PR #249
<cris__> ... any objections?
ege: any objection to merging?
<cris__> ege: go
ege: merged
PR 251
<kaz> PR 251 - Temporary Section Reorg - Part 5: Interaction Patterns
ege: getting rid of the appendixes
ege: we had a long section for binding properties
… but it explained good concepts
… in a easy format
… I kept thoes ideas
… and moved in the right section
… cris should review the PR because it has examples with the modbus
… it explains how binding should really work
… I won't merge it today
cris: the examples are pretty concrete and they introduce a dependecy with the binding docs
… should we use a more abstract syntax? i.e. foo protocol binding
ege: I see your point, but then is too abstract
cris: yes indeed
kaz: I would like to see a diagram to explain the concepts better
<Mizushima> +1 kaz
ege: it should go to the introduction
… I can tackle it in the PR
… any other ?
s/
ege: Koster, can you have a look at it?
mk: ok
ege: there is still a lot to discuss but we need to move to TD
Thing description
<Ege> https://
PR 1772
<kaz> PR 1772 - Add table numbers and captions using new respec option v.2
ege: I create a PR and then cristiano took over
… the overall idea is to introduce captions
… to make it easer to refer the tables
… it create numbers
… so that we can refer to table
… there is no way to refer to the tables
… you can't click the table
… I think we can still merge it
cris: there is a workaround
ege: it is good enough
cris: about respec, I checked the code it easy to fix
dape: remember that figures are not clickable either.
ege: true
cris: +1
ege: I would not stop the PR
dape: if we can fix it in the respec we can wait
cris: it depends how much they are fast to approve PRs and ship it
ege: I would merge the PR anyway
kaz: examples have clickable links, we can take them as examples. Also we can look into the other existing specifications by the other WGs.
… However, please note that this is rather a "nice-to-have" kind of addition. So if it takes too long to see how to do that, we can simply live with the current status.
ege: yeah
cris: yes, I agree
ege: I looked around and tables are not used that much
… I'd merge it and if there is an update we would have a follow up pr
dape: I'm not objecting, but currently some table has the caption but others don't
ege: ok let's wait for the next week
ege: ok than we are done
… any AoB ?
[adjourned]