Meeting minutes
Agenda
Ege: I would add topics to the agenda
<Ege> https://
Ege: on PR and an issue
<Ege> https://
<Ege> https://
<Ege> https://
Sebastian: welcome back to our weekly td web meeting
… no guests today
Sebastian: we have a couple of PRs in the pipeline, plus we have to review previous minutes
… we'll also discuss the publication schedule
previous minutes
<kaz> vF2F minutes
Sebastian: we discussed new features of the next TD version (1.1)
… also new vocabulary terms
… a couple of typos
… new uri scheme for Security information
… Morever we talked about the publication readmap. We'll review it today
… the current plan should be aligned with our test fest
McCool: may 15 is a Saturday, probably we have to reschedule the deadline
… possibly a couple of days earlier
Sebastian: let discuss it later
Sebastian: then we had the presentation from Micheal Koster about SDF outcomes in the plug fest.
… I am seeing that my slides are not linked in the minutes
… we should add them
McCool: we are missing a few slide decks, we need to clean up the minutes a little bit.
Sebastian: later new had a presentation about Conanicalisation,
… also here I don't see link to the slides
… finally we had an update to the latest news from IoT Schema by Michael Koster
… minutes looks good, we need only to fix the links
… other than that minutes are approved
last td meeting minutes
<kaz> March-10
Sebastian: update from Cristiano about the new modbus document
… then we looked at a bunch of PRs
… 1058 should be merged, we'll check it later
… 1061 is still open
… 1065 still open too
… then we reviewed 1053 issue about additionalResponses
McCool: I was working on it but I found a problem in security schemas definition.
… so first we need to fix it
… it would be great if someone could provide a PR fixing it
… there are several issues
… current draft is broken, it does not have securityDefinitions
Sebastian: it might be a problem with the render script
McCool: we should definitely fix this problem befor the CR transition
Sebastian: I'm seeing a pattern, there are also other definitions broken
… I have the impression that is a render script issue
McCool: there're also some problems insdie the ontology
Sebastian: do we have a tracking issue for this?
McCool: we should
McCool: base is also missing
Sebastian: I think it was removed by accident
… I'll try to understand what happened
Sebastian: back to the minutes, we have a PR from Cristiano refactoring TM-to-TD generation
… any objections about the minutes?
… ok minutes approved
publication plans
Sebastian: we already a draft schedule, the next WD should be published around middle may
McCool: I am proposing 12 for taking a resolution
… and froze the current document soon
… april 28 could be a good deadline
Sebastian: only two weeks from now?
McCool: we can move it to May 5th
… probably the same will happen for discovery
… resolution should be May 19th
Sebastian: is it ok ?
Ege: it is tight, but ok
Sebastian: yeah, but it is still a WD
… we have time to later nail down major issues
McCool: indeed we should aim for small fixes for May
Sebastian: ok roadmap noted
Resolution: the plan for the next WD TD 1.1 would be: call for review on May 5th and do resolution for publication on May 19th
deferred issues
Sebastian: as usual please check the postponed issues for TD 2.0, speak up if you would like to address them in the current version
PRs
Binding Template PR 112
Sebastian: let's start with PR 112
Ege: it comes from vF2F
<Ege> https://
McCool: since it depends on an Architecture update, let's defer it to Arch call
Sebastian: relating to this I have to remove Thing Model definition and add it to architecture
… ok any objections to merge it?
… merged
TD PR 937
<kaz> wot-thing-description PR 937 - WIP: swap securtiy and securityDefinition in context file
Sebastian: TD PR 937 is wip, victor is also involved because is touching the ontology and shacl definitions
… then we have proof and proofChain section PR
McCool: it is related to signing but is based on the outdated jsonld proof
… still working in progress
TD PR 945
<kaz> wot-thing-description PR 945 - Simplified inline security definitions
Sebastian: 945 is deferred
TD PR 1058
<kaz> wot-thing-description PR 1058 - Add JSON pointer assertion to definition of body sec location
Sebastian: then we have 1058 about JSON pointer assertions
McCool: I changed body to accept a json pointer but there's also other weird issues that I tried to fixed.
… possibly render script issues
… we should remove these file from git tracked list
<kaz> s|let's start from 112|PR 112 - remove terminology since it is moving to architecture|
McCool: the real content talks about body content. It should be a json pointer which will not starting from the root, it is a relative pointer. So it cannot start with #
… there are implementation challages
… because this pr allow automatic insertions that processor should be able to handle
<kaz> i|937 is wip|wot-thing-description PR 937 - WIP: swap securtiy and securityDefinition in context file|
McCool: the automatic insertion helps to reduce redundancy cause the designer can avoid to add the security information in each data schema
Ege: some history: in the current spec we have body security schema, but it was not really usable cause you couldn't point to any specific keyword in the body.
Ege: should I use it even with readproperty?
… readproperty does not have inputs
McCool: body makes sense only for POST requests
… we probably need to force implementers to use POST
McCool: what webthings io does about local security?
Ege: they don't really have any local sec
… by the way I would open an issue about adding a ednote saying that body should be only used when the protocol allows it
Sebastian: it would be nice to have this PR also for testing
… any objection to merge it?
… merged
TD PR 1061
<kaz> wot-thing-description PR 1061 - WIP: Fix cardinality of Link.rel
Sebastian: marking 1061 as ongoing
… possibly related to problems in the render script. Array is spawning where it shouldn't
… victor is working on that
TD PR 1065
<kaz> wot-thing-description PR 1065 - fix: the "required" keyword was placed incorrectly in the TM schema
Sebastian: ignoring, I am working on another PR about the same topic
TD PR 1077
Sebastian: important PR about transforming jsonld to rdf and back
… still working progress, it has something to do with framing
TD PR 1085
<kaz> wot-thing-description PR 1085 - WIP: Add Validation Section
Sebastian: from mc and it's about validation
McCool: there's three levels defined
… maybe leave out the highest validation level
… it needs input and discussion
… please comment
… it also tries to fix assertions and other minor problems
… full validation might even involve to test the output of the WebThing
… it needs input
TD PR 1086
<kaz> wot-thing-description PR 1086 - Add section to define Canonical serialization
Sebastian: possibly we can merge this
McCool: a TD processor should not re-order array elements inside a TD otherwise the canonicalization would be broken.
Daniel: removing duplicates it is hard
McCool: implementing Canonical serialization is challenging itself.
… some json processors reorder properties in alphabetical order.
… it might make streaming processing difficult
… I am stating an exact order in the PR
Daniel: what about different prefixes?
… valid in jsonld?
McCool: I think they should be expanded using a jsonld processor
Cristiano: so I can't use prefixed properties in a canonical TD
McCool: yeah you should not leverage on prefixes in jsonld is an antipattern
Cristiano: what happens with the default context ? do we have an assertion about it?
McCool: yes we should have it
Ege: true
Sebastian: we are missing an example
McCool: the thing is that a canonical td must not have withespaces, so the example would be a blob of text
… but we can add a pretty print button
Daniel: or we can do it for every example
… readable example and a button for canonical form
McCool: no all examples are not real tds
Cristiano: we can skip the not real tds
McCool: yeah we need a library that is able to derive a canonical form
… a bit annoying to implement
Cristiano: we can reuse it even in node-wot
McCool: also in discovery (e.g. db serialization)
… I'll write this tool myself
Sebastian: let's review the PR next week then
TD PR 1090
<kaz> wot-thing-description PR 1090 - init tmRef
Sebastian: the PR introduces the import mechanism in the TD
… is taken from sdf
… basically you can take the definition from other TDs
Sebastian: you can mix it with extends
Sebastian: we had one comment from Jan to clarify if you can import an element from a TD that extends another one
… is also speakinga bout overriding
Cristiano: seems reasonable to me
Koster: in sdf we say that you should not change the semantics
Cristiano: yeah, we should be more careful for extending models rather than importing.
Kaz: do we really need this extension for thing descriptions?
… we already have links
Sebastian: these features are useful
Kaz: do we really need to complicate the TD to have all this "programming language" features?
Sebastian: just to clarify this feature is for TMs
Kaz: how to deal with TMs is already challenging
Sebastian: yeah it is, maybe in the future we could move in a dedicated specification document
Kaz: indeed a while ago I proposed having a dedicated note for TMs
TD PR 1092
<kaz> wot-thing-description PR 1092 - rename required to tmRequired + top level definition
Sebastian: required keyword was found to be problematic
… the PR renames required to tmRequired
Cristiano: it is good, but why did not used tm as jsonld prefix?
Sebastian: yeah it would be another way
McCool: yeah it would be more consistent with also what we are doing for TDD
Sebastian: I like it but it might be small
… I am not against it
Koster: +1
Sebastian: marking as not ready to merge, I'll go down with the new namespace solution
Sebastian: could we embed it inside the TD context?
McCool: yeah
Ege: what are the implications when a TD does not follow the required rule?
Sebastian: it is a validation issue
Koster: it is actually another level of validation
Ege: I understand, but what happens if I have a TD that does not follow the TM?
McCool: I would add a clause in the full validation
Ege: I wondering if it has real functioning implications
<Ege> https://
Ege: I'd like to invite Jan to next call
Sebastian: ok
Kaz: is the TM section normative?
… if not we don't need assertions
Sebastian: let's talk about it next time
Sebastian: adjourned