<kaz> scribenick: Ege

Agenda review

<kaz> Agenda

Kaz: given the discussion during the main call, maybe we should ask Farschid from Frauenhofer to join the TD call as well at some point

Sebastian: he can join any calls now. Let's ask him to join the discovery call first

Previous minutes

<kaz> Apr-3 minutes

Sebastian: (reviewing the last minutes)
... Any objection to publish the last minutes?
... no objection it seems, publishing

Repository

<kaz> wot-thing-description repository

Sebastian: Should we keep the repository as it is or make a new one
... I tried to understand how other groups do it

Kaz: jsonld didn't use github for the first version

Daniel: there are many pitfalls to creating a new repository

Kaz: I also agree with Daniel

Ege: Also you would need to copy the issues but their labels as well. For a project of this size, it is dangerous and checking that we copied correctly would be a difficult manual task

Sebastian: regarding versioning, we can keep the v1.1 idea and if the changes are substantial, we can do a version 2.0

<kaz> https://github.com/w3c/imsc

<kaz> Kaz: IMSC example above. TTWG manages several versions of IMSC spec within one repo

Kaz: IMSC example shows that they have different branches for different versionss

Sebastian: so let's do it like this. I will organize this until next week

<kaz> (note that we should add links for the recommendation version on the README.md :)

<sebastian> proposal: the group decided to keep the TD repository for the next version. The repository will be organized in similar way as IMSC by TTWG.

RESOLUTION: the group decided to keep the TD repository for the next version. The repository will be organized in similar way as IMSC by TTWG.

Sebastian: should we have a requirement that a 1.0 processor can process 1.1 but just not understand the new keywords
... json-ld 1.1 is a substantial change for example

Ege: but I think a 1.0 parser will not fail trying to parse 1.1 ?

Sebastian: but it will not be able to understand new terms and ways to parse it

Taki: new implementations are starting and it would surprise them if we publish a new REC in 6 months that breaks their implementations

Zoltan: we need to be able to tell two versions when consuming and producing them
... a service can automatically convert them
... if the changes are backwards compatible, you can nearly omit the versioning since it would be automatic

Kaz: I also agree with Zoltan and Taki

<kaz> Kaz: we could add features but should not change the meanings/behaviors of the existing features so that the v1.1 processor could safely process the v1.0 TD instances

https://semver.org/

Ege: I also agree with the rest, also semantic versioning is against incrementing the second number of the version there is a breaking change

Sebastian: so it is good to see that the group has a consensus on that. We don't need to decide now

Issues 842

Issue 842

Related PR 891

Daniel: the problem was that the fix was not in the working version

Sebastian: then let's merge
... and close the issue

Issues 889

<kaz> Issue 889

Sebastian: he wants to define the length of a string

<kaz> JSON Schema in RDF

Sebastian: we can update the JSON Schema vocabulary to include these

Ege: I am not against adding these two words, it not a big addition anyways, but I would force people to document their implementations and provide input for the implementation report so that we don't have to generate dummy TDs

<scribe> ACTION: ege will follow up on isssue 889

issue 890

<kaz> Issue 890

Koster: I am not sure if this is the appropriate term to use

Kaz: you should reformulate the issue to clarify the requirements. possibly waiting until some action is done and/or some event is received

(some more discussion about Ege's idea)

<kaz> scribenick: kaz

SMIL 3.0

SCXML as state transition controller as another fyi

Kaz: maybe what you want is something similar to SMIL or might be SCXML
... but we'd like to understand what you want a bit more precisely
... so would suggest you elaborate your use cases a bit more

scribenick: Ege

Sebastian: Ege will work on reformulating the issue and make it clearer

Issue 892

scribenick: kaz

Issue 892

Ege: HTTP binding for providing historical events
... would ask Victor for opinions

Zoltan: what would be the benefit to include this into the standard?

Sebastian: motivation for the use case?

Zoltan: similar example with telephone systems
... keeping call history, etc.
... but should be handled separately

Koster: not sure how to deal with this, maybe something is missing, though
... but how to build into TD's interaction affordance

Zoltan: more like fetching status

Sebastian: maybe we should involve Ben as well

Kaz: yeah, think this is related to TD management mechanism like state transition
... we should clarify the requirements a bit more

Taki: some industry use case values projection
... but we need to clarify the use case about how to handle it

Sebastian: yeah, good point to ask the proposer

Ege: yeah, the way how to handle the history would not be compatible with the current TD

Sebastian: we need more clarifications

<Ege> https://github.com/RoboPhred/wutwot/

Ege: link for this proposer's implementation above

Sebastian: JS-based?
... (looks into the repo)
... interesting
... maybe we can invite this guy to our meeting

Binding templates

<Ege> https://github.com/w3c/wot-binding-templates/pull/95

Ege: created a PR 2 weeks ago
... basically, here I collected examples from Issues
... Zoltan and Koster have given comments

diffs

Ege: removed section 4.4
... there were problems with examples
... id in brightness, etc.
... was not clear how to add new binding
... the examples have many diffs but minor changes
... would like to merge this PR 95
... any objection?

(no objections)

Ege: merged
... any other updates regarding vocabularies?

CoAP vocabulary within the repo

Ege: how to handle that?
... and any updates?

Sebastian: should organize the TD repo as well for the JSON Schema resources

Ege: where to put it?

Sebastian: make sense to collaborate with IETF
... not sure where to put the resources at the moment
... but should start collaborative work
... could start with people who are already involved

Ege: we should be careful about method code vs human readable features
... no consumers (=application developers) use codes

Koster: people would use names though codes are also defined

Ege: we should work on MQTT as well

Koster: TD doesn't have to care about the detail

Ege: we just care about vocabulary used by TD

Sebastian: btw, who created this coap.ttl file?

Ege: think it's done by Victor several years ago
... (adds comments to Issue 93)

Issue 93

Ege's new comments

Ege: anything else?

(none)

[adjourned]