Meeting minutes
minutes review
<kaz> Mar-29
Ege: Any changes to the minutes?
… OK to publish
binding template issues
Ege: have gone through and tried to resolve
issue #232
<kaz> Issue 232 - Next WG Note Path
Ege: any objections to close?
issue #213
<kaz> Issue 213 - Need for improving the description within the Binding Templates document
Kaz: we are already working on the next charter which includes this, we could label for next charter
… create a new label for "refactoring"
Ege: done
… we can use this label for other issues
issue #152
<kaz> Issue 152 - Use case due diligence
Ege: the PR has already been merged, we can close
issue #110
<kaz> Issue 110 - Removing Section 4.3
Ege: this is very old and out of date
… not relevant anymore, so we can close
issue #97, CoAP ontology
Ege: this is done, so we can close
issue #135
<kaz> Issue 135 - Consider removing section 2.2 HTTP Default Vocabulary Terms
Ege: we will maintain the HTTP default vocabulary in the binding template documents
… any objections?
… closing
issue # 239
<kaz> Issue 239 - Disallow changing prefix of binding ontology
Ege: propose to create a general assertion for ontology prefixes
… should the prefix recommendation extend to TD in general?
Daniel: in node-wot we check for known prefixes
… if we can agree on a fixed set of prefixes
Ege: there might be a problem with versioned ontologies
Luca: if TD producers use JSON-LD, there could be prefixes for adding meaning. In the protocol binding, we have a registry
… there is a concern that JSON-LD would not be fully supported
… with bindings, we are required to understand the prefixes
… in the general case, the prefixes may be optional
… the context will make it clear what the prefix is
… the prefix in the binding enables operation with plain JSON
Kaz: does this mean specifying namespace in the context?
… changing TD ontology prefix is a different thing from changing namespaces
… we should consult with JSON-LD experts on this
Ege: Gregg Kellogg commented on this kind of issue at one point
Kaz: as W3C WoT WG, we can't specify this kind of implementation detail, and should only be a recommendation, not a "MUST" but maybe could be a "SHOULD". However, we should talk with the JSON-LD experts and VC/DVD experts, who also have the same issues, because we, W3C WoT WG, should be inline with their approaches.
Cristiano: either the consumer is a JSON-LD capable processor, or not
… the downside is that some applications may need to select prefixes that don't conflict with the fixed ones
… we need to keep our approach consistent with JSON-LD
Luca: the problem is that a valid JSON-LD can use any prefix it wants
Luca: valid TDs would be rejected if they don't have context for the prefixes
… if we mandate a full JSON-LD processor on the consuming side, it is wasteful
… if we don't claim to be JSON-LD compliant but JSON-LD -like markup, then we can expect people to implement the prefixes
Ege: don't think we can accommodate the generic case
Luca: maybe there is a reduced capability way to process TDs that a non- JSON-LD processor can use
… such that only a JSON-LD processor can use the full functionality
… how much burden we want to put on who
Cristiano: a JSON-LD processor would be able to use all of the extensions
Luca: there is no place where this issue is clearly stated in the documents
… right now we aren't mandating a JSON-LD processor
Cristiano: a lot of the tools depend on JSON-LD processing
… but we expect a lot of implementations could use plain JSON
Koster: point out that the td+json content format is the governing document for plain JSON processors
protocol vocabularies
<kaz> Issue 216 - Instructions on how to create a vocabulary and publish should be provided
Ege: how do we document the protocol vocabularies?
… should there be a required md file?
Cristiano: the md file could have links back to the other documents
Ege: maybe the vocabulary is published by a third party
<kaz> W3C Alternative and Augmented Communication (AAC) Symbol Registry
Kaz: we should look into how existing registries work, as examples
Jan: agree with creating a md file with links
Kaz: concerned about us creating a mismatch with other W3C registries
PRs
PR # 275
<kaz> PR 275 - feat(coap): add conformance section
Ege: this adds conformance
… we should add this to the next charter
Jan: so far there is no conformance section in the Modbus document
Ege: create issue #278 for Modbus conformance
… merging PR #275
… added issue #297
PR # 276
<Ege> https://
Ege: clarifies the use of content format
… how producers and consumers use content format, including content negotiation
… this would be a good structure for other protocols
Ege: ok to merge?
… merging
Thing Description
updates
Ege: added labels to 7 open issues to propose closing
PR #1791
Ege: adds version information to the respec content
PR #1791
<kaz> PR 1791 - Add references to TD 1.0
Ege: changing assertions, however fixing link to reference to point to the right specification
McCool: agree this change is to capture the intended meaning and does not impact implementations
Ege: also added a link to previous recommendation
Ege: validation fails, but can be ignored in this case
… any objections to merging?
… hearing none, merging.
PR 1790
<kaz> PR 1790 - Editorial fixes for issue 1735
Ege: relates to issue 1735
<kaz> Issue 1735 - Minor editorial changes for PR
Ege: set of editorial fixes
… some of which are inside assertions
… adding a missing "a", italicizing some terms that are being defined for "form level" and "Thing level"
McCool: one concern is that italics is not used anywhere else, right?
… seems it would be more consistent to define them in "Terminology" and use caps
Ege: ok, will look into doing that, might add a number of definitions however; also, terminology is informative
PR 1786
<kaz> PR 1786 - Update version td-json-schema-validation.json
Ege: this is just updating the publication date of the td-json-schema-validation.json
Ege: merged
PR 1792
w3c/
Ege: this fixes the examples to use the right context
… all examples are of course informative, so this is editorial
… merged.
Issues
Ege: first, look at "Propose Closing" issues
… oldest first
Issue 1607
Ege: about mandating semantic versioning; but would then need to define what semantic versioning means
… is also now a charter work item for next charter to address this
… so resolution is to leave in the recommendation to use it, but as informative text
… we also do have a reference to SEMVER
… trouble is we don't really define what is meant by minor update
Luca: minor adds functionality, does not break compatibility
… think it is straightforward
… patch is for bugs, i.e. fixing mistakes in titles, etc.
… major is for anything that breaks compatibility
McCool: we can't make it an assertion at this point, however
… so decision is just about whether or not to have this informative text
Luca: what is this the version of?
Ege: of the TD itself; not of the software supporting it
Ege: agree on how we should handle versioning, but do we have the text in the spec
Cristiano: ok with mandating SEMVER, but are these policies that are difficult to test?
McCool: we *might* be able to define this in terms of testable changes to the TD
Luca: at the directory level that might be implementable
Kaz: ok with this direction, but we need to gather more information about developers expectations and best practices
… for the next charter discussion
Ege: at any rate, will relabel to "defer to TD 2.0"
Issue 1612
<Ege> Issue 1612 - [OracleReview] 5.3.2.7 StringSchema
Ege: some missing links to various RFCs, related PR does this
<Ege> w3c/
Ege: see PR #1650
… references added to table.
Ege: I think that means this issue is closed, as the PR was merged.
Issue 1673
<Ege> Issue 1673 - "A Thing acting as a Consumer" -> "A Consumer"
Ege: "A Thing acting as a Consumer" -> "A Consumer"
… phrase is used in several places
Jan: there is a linked issue, I think
… I think it has been resolved already
… Issue 1675 is about expansion of IoT, related PR #1693 also fixed this problem
Ege: ok, issue closed.
Issue 1705
<kaz> Issue 1705 - Example 4 is empty if "default values" checkbox is off
Ege: was a bug in examples, perhaps fixed now?
<Ege> https://
McCool: what browser?
Ege: works in firefox
McCool: also chrome
Daniel: perhaps whoever reported this bug had blocked scripts
McCool: suggest we close this, ask Michael Lagally if he can still reproduce it and how; if so, we can reopen
Issue 1719
<kaz> Issue 1719 - What to do with the profile keyword
Ege: what to do with profile keyword if profiles is not a rec?
… conclusion was to keep it
McCool: also, if not at risk, we can't remove it at this point anyway
Issue 1734
<Ege> Issue 1734 - How to specify request headers?
Ege: more of a question than a change to the spec
… and the question was answered to the asker's satisfaction
Ege: closed
Issue 1674
<kaz> Issue 1674 - Mention that protocol bindings can also be defined in profiles
Ege: still under discussion in Profiles
AOB
McCool: any followup from TD Dev Meeting?
Ege: a few new test results from SayWoT! team, already submitted; may be some more
Kaz: there was also a JP version of the meeting, will try to collect feedback as well
Cristiano: seems to also be a mistake wrt node-wot, will attempt to fix
Some more Binding topic
Issue 226
<kaz> Issue 226 - Changing the Platform Bindings to Combination Bindings
Ege: since we have time, a bit of discussion of issue 226 in wot-binding-templates
… this is a naming issue, basically what to call bindings that have multiple aspects
… is "Platform Bindings" appropriate?