Meeting minutes
minutes check from last week
<kaz> April-14
any objections befor publication the minutes?
no
Guests
Sebastian explains about the W3C patent policy
Jan introduces himself
<kaz> W3C Patent Policy
Jan is from University of Bremen
working in the chair of Carsten Bormann
publication plans
plan is to have everything ready until May 5
get resolution for publication on May 19
WoT Binding
Ege: shows an issue from the binding
https://
<Ege> https://
<Ege> https://
<Ege> http://
<Ege> https://
Ege: explains some example about request -response with MQTTv5
Jan reports some experiences with zigbee2mqtt
Ege: proposal is to introduce subprotocl: mqv:requestResponse
this would work with MQTTv5
<McCool> (heavy echo, if not speaking pls mute)
for MQTTv3.1.1 "mqv:responseTopic": "<topicPath>"
Cristiano: shall we use a different field such as version?
there was the discussion to use properties for the retain feature of MQTT
Koster: in SDF we have decided native subscription model
Sebastian: there was a presentation from the MQTTv5 authors and mentioned that you should not really use MQTT for req / res.
Koster: we should not force people implement req / res with events
cris agrees
Sebastian: retain flag in the TD is just a hint
Cristiano: the versioning problem is also related to other protocols
Ege: we can use mqv:version
Cristiano: we can do it more in a generic way
<mjk> I need to drop for the ASDF interim meeting
<Ege> https://
<Ege> http://
Ege: shall we support the v5 feature?
Sebastian: depends how v5 is adopted
Ege: no many broker have implemented it
proposal would be to stay with the MQTTv3.1.1 approache which does not come with req./res.
<cris> +1 for this direction
Defer issue to TD 2.0
Sebastian: please look at the issues labeled with "2.0"
PRs
PR 1086
PR 1086 - Add section to define Canonical serialization
McCool: (describes the PR)
… would propose we merge this as the basis of further discussion
… removed duplicated rules, and it's much simpler now
Sebastian: (goes through the preview for section "6.5 Canonicalization")
McCool: maybe there are some mistakes there
… but can fix them
… currently the entries are put based on the alphabetic order
… I added an assertion on prefix to be maintained
… any processor needs to handle that
Sebastian: theoretically, we can use any kind of prefixes
McCool: right
Daniel: replacing geo, etc. to full notation?
McCool: JSON doesn't handle prefixes
… so we need to use some library
… canonicalizer handles prefixes as string rather than object
Kaz: why don't we add an Editor's note about those possible questions and then merge this PR itself?
McCool: either is fine, adding an Editor's note or adding small edits
… before merging
… URLs must not be modified
Sebastian: (adds several comments to PR 1086)
… fix typos, add assertion that a TD processor must not modify the URLs
… McCool adds those changes and then merge the PR
… can you remove the commented out part as well?
McCool: can do
Cristiano: thinking about prefixes
… we can say the most common practices is removing the prefix
McCool: right now the geolocation proposal to be fixed
… with certain prefixes to make the processing easier
… in theory, JSON processor need to see some table for the processing
… can depend on prefixes from protocols
Cristiano: how/which document to fix it?
McCool: canonicalization needs to be fixed
… certain fix for prefixes needed
Sebastian: so please apply the fixes and then let's merge the PR
McCool: ok
PR 1085
PR 1085 - WIP: Add Validation Section
McCool: this is related to validation
… would focus on the normative spec first
… not ready right now
… but would like to get feedback
PR 1090
Sebastian: comments by Jan there
… we should not be more relaxing
… so can be more restricted
Sebastian: (goes through the changes)
… we can copy definitions to new ones
… and get new id:value pair
… the semantic meanings should be the same
… introduced new examples to provide better understanding
… overrides the maximum
Sebastian: (goes through the preview)
Jan: is having maximum as 100 too restrictive?
Sebastian: (shows the ASDF draft)
Jan: what about TM extending another TM?
… is that possible?
Sebastian: some example there (around lin 5196 from the HTML code)
… would like to suggest we merge this PR 1090 as the basis for the further discussion
… any objections?
(none)
(and merged)
PR 1092
PR 1092 - rename required to tmRequired + top level definition
Sebastian: renaming needed
… also need assertions for validation
McCool: playground should be also updated
Ege: I should include this change
McCool: will apply the changes
PR 1085 - WIP: Add Validation Section
Sebastian: quickly skim PR 1085
… may I merge PR 1092 now?
McCool: just wondering which the current spec use "ref" or "reference"
Sebastian: "ref"
… any objections to merge PR 1092?
(none)
(and merged)
PR 1095
PR 1095 - Two step generation of the TD from a TM
Cristiano: not sure if all the processors need to follow these two steps, though
Sebastian: note that you just provide the template.html
… but should provide index.html as well
Cristiano: ok
related issue 1047 - Two step generation of the TD from a TM should be clear
Sebastian: a bit concerned since this PR 1095 is very big
… should be split into several smaller PRs?
McCool: multiple smaller PRs would be better to handle
… note that every assertion must use the RFC2119 keywords
Daniel: some typo there
… "tmRequired" should be "tm:Required"
Cristiano: right
Jan: is partial TD introduced yet?
Sebastian: good question
… there Terminology section should have the definition
Daniel: the next publication version should include it (though the current published version doesn't)
<cris> Partial TD definition
Sebastian: need to have a look
… the definition is valid for the TD draft (at the moment)
… maybe it would be better where the definition is done (=within the WoT Architecture spec)
Kaz: note we're out of time
Sebastian: let's continue the discussion next week then
… thanks a lot for your contributions
… and thanks for your participation, Jan!
Jan: no problem
[adjourned]