Meeting minutes
<thjaeckle> I just use the initials of the speaker and write?
Agenda
<thjaeckle> sk: Outlook to next week: A guest presenting the BACnet Binding for WoT
<thjaeckle> sk: would like to look at a couple of PRs to merge today
Daniel: pub schedule was updated today
<dape> https://
<dape> number 4
Sebastian: final goal today: freeze of all the sections to see in the TD WD
<dape> --> pr
Kaz: regarding the BACnet binding agenda item for next week, would it be a presentation or are there concrete use case description, etc., for the binding template?
Sebastian: talk about BACnet binding and the opportunities next week
kaz: whichever is fine (just a presentation or concrete proposal) but wanted to clarify the topic
Prev minutes
Sebastian: checking meeting minutes of last week: agreed last week that "dataResponse" element is provided in event affordance
Sebastian: decided against "schemaDefinition" on global level for TD 1.1 last week
Sebastian: last week a feature freeze for upcoming WD was agreed on
<kaz> (minutes approved)
Wide reviews
Sebastian: requests done for accesibility, i18n, security groups
<kaz> Accessibility
<kaz> I18N
<kaz> Security review preparation
McCool: hope to have security issue done by next wednesday
Sebastian: TAG is very busy, that's why we already setup request for review, expecting them to review the request in couple of months
Sebastian: let's look at PRs
Pull Requests
PR 1340
<kaz> PR 1340 - Manifest
Sebastian: manifest PR #1340 regarding "manifest" in links
Sebastian: idea is to create another PR in order to only include relevant text change in it
<cris> +1
Sebastian: manifest PR will be included in WD
PR 1368 - $id field in index template
<kaz> PR 1368 - Adding $id to JSON Schema
Ege: good practice to add "$id" field
Ege: if using multiple JsonSchemas, one can use "$id" field to reference them
Sebastian: merges PR 1368
PR 1376
<kaz> PR 1376 - refactor: remove MD5 from alg example list
Sebastian: we agreed to not include the enum with existing algorithms any more
Daniel: the JsonSchema "ext-td-json-schema-validation.json" was not updated for 5 months, it seems outdated
<kaz> ext-td-json-schema-validation.json
Sebastian: this document should not be used anywhere
McCool: reason we have it is we have a strict version and a version allowing extensions - the none-strict version allows using extensions
Ege: does not know this file, never used it
Kaz: can we clarify which schema files are used in playground?
<Ege> https://
Sebastian: creates issue to discuss removal of `ext-td-json-schema-validation.json`: #1386
PR 1377
Add dataResponse to event affordance
Sebastian: thinks addition of "dataSchema" is enough for supporting the webhook use case
Sebastian: merges PR 1377
Daniel: fixed PR 1376 (circling back to MD5 PR)
Sebastian: merges PR 1376
PR 1380
Sebastian: main intention to have the "profile" in JsonSchema for validation
Sebastian: merges PR 1380
PR 1383
Ege: additionally defined that uriVariables on interaction affordance level take precedence when also defined on top level
Sebastian: inspects example with top level forms and top level uriVariables
Ege: btw, this also solves the issue how to "readmultipleproperties" via HTTP
+1
Sebastian: merges PR 1383
Sebastian: other PRs to decide/look at after the WD
PR 1360
Update Security and Privacy Considerations
McCool: not completely done, but still ok to merge for the WD
Sebastian: ok with the PR to merge as is
McCool: will do another PR to just include the actual changes
Check Issues
Issue 1384
<kaz> Issue 1384 - A TD should be able to define which Properties are required
Sebastian: mentions "additionalResponses" in order to define error codes / responses
Ege: thinks "required" is the wrong english word
Daniel: what happens if there are multiple forms? should a consumer try other forms until it can access a propery not present in the first form?
Issue 1368
Refactoring JSON Schema to have less duplication
Sebastian: marking with V1.1 label
Issue 1354
ThingModel composition and TD relation
Sebastian: not yet a solution to avoid the confusion of the composition concept
Thomas: proposes to explain limit of extension, that only one model can be extended, which can be solved by using composition instead
<McCool> (aside: cleaned up PR for security and privacy considerations now ready: https://
Kaz: a nicer example would help, if possible to provide typical composition example
McCool: examples in the wild: multi sensors and power outlets
McCool: first example being a collection of different things, second one a collection of same things
McCool: multi sensors is probably a more common example
Sebastian: a room could also be a TM and could have different submodels in there
McCool: a room is more of a location consideration
Sebastian: example from last test fest: a line which contains multiple machines as submodels
McCool: multiple power outlet strips is also a good use case to consider how to model that
Koster: brings up also LED strips example
McCool: the point is that for an outlet strip, you reference one defined submodel outlet several times in the top TM
McCool: examples for both, multi sensor use case and mutliple power outlet strips, would help
Sebastian: asks for the oneDM light strip example
Sebastian: let's go for a more clear example
Issue 1347
Unclearly defined DataSchema "type"
Ege: there is a PR which was accidentally merged and should be reverted
Ege: this breaks backwards compatibility
Sebastian: we should do a new PR reverting that
Ege: array of types was intended as a basic "one of" construct
Daniel: is it intended to be possible in TD 2.0?
Ege: from his point of view: yes - should be possible in TD 2.0
Ege: will provide PR reverting that change
Sebastian: Ege can merge directly to have it available in WD
McCool: the Security and Privacy considerations PR is ready
PR 1387 - Update Security and Privacy considerations for WD
<Ege> brb
Sebastian: merges PR 1387
Sebastian: do we have some other business talking about?
<sebastian> proposal: from today we freeze the normative sections for TD 1.1 REC
<sebastian> proposal: from today we freeze the normative sections for TD 1.1 CR candidate
RESOLUTION: from today we freeze the normative sections for TD 1.1 CR candidate
<kaz> [adjourned]