<kaz> scribenick: Ege
<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
<kaz> Apr-3 minutes
Sebastian: (reviewing the last minutes)
... Any objection to publish the last minutes?
... no objection it seems, publishing
<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
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
Daniel: the problem was that the fix was not in the working version
Sebastian: then let's merge
... and close the issue
<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
<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
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
scribenick: kaz
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
<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
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)
Ege: anything else?
(none)
[adjourned]