<scribe> scribenick: kaz

Agenda

<Ege> https://github.com/w3c/wot-thing-description/issues/848

Ege: would like to talk about the above issue if time permits

Prev minutes

June-5

Taki: anything to be fixed?

(none)

Taki: approved

IRTF workshop

draft minutes

Taki: anything to be mentioned here?

Kaz: McCool and Lagally gave information on the basics
... maybe we can ask Koster and Ege about some brief report on ODM an Hypermedia

Koster: presented TDT vs ODM
... here TD annotation and creating TD based on ODM

TD issue 903

Koster: how to generate TD using TD template

Taki: related to issue 903

Kaz: gave a comment about how to handle state information
... might be better to handle state information separately from the properties
... need further discussions

Koster: yeah, how to handle state
... developers could look into human-readable definitions
... how to make that machine-readable is what we need
... SCXML might be one possibility
... we have also have an example by Carsten abut a coffee machine
... we could probably work on that
... human-readable description vs machine-readable semantics
... that was good discussion at the workshop

Taki: ok
... let's have further discussion

Koster: ODM have objects and thing class
... how to deal with that using TD?
... not really sure at the moment
... e.g., discovery based on the capability
... RGB affordance, HUE saturation, etc.
... would look into the note again

Taki: ok
... if you remember any points, please put them into issue 903
... what about the hypermedia topic?

Ege: talked about that
... Matthias contacted me after the workshop
... and gave a comment to issue 899
... would talk about that during the next agenda item (for issue 899)

Taki: ok

Doodle poll for CoAP RDF discussion

Doodle

Kaz: thought we were planning to add some more slots from Tuesday

Ege: Tueday would be better for me too, and probably Klaus as well

Kaz: so far, Victor is not available for either of the slots

Taki: right

Kaz: probably we need Victor's participation as well
... so let's check with Sebastian

Taki: will send a note to him

Kaz: tx

Issue 910

Issue 910

Taki: issue raised by Zoltan

Zoltan: just wondering about the best practices for TDs
... actions using URI variables
... in Example 21

Example 21

Zoltan: not following the narrow-waist model
... would be good to have why not using input
... wondering what would be the right way
... Ege provided another example of a coffee machine from node-wot
... seems a fair example
... but we don't really have good description
... how to handle multiple parameters, etc.
... there is a gap

Ege: strongly agree
... Example 21 is not a good example
... so we should provide all the affordance, property, action, event

Zoltan: if you could add consistency
... also should put more text as well

Ege: could have some "info box"?
... like an Editor's note

Zoltan: Examples are kind of Best Practices
... all the examples in the spec should show best practices

Daniel: we would see best practices but need to see what we have
... and what we shows
... there are big differences here
... should not say this is a best practice here

Zoltan: we have interaction affordance
... interested in what is possible and what is not

Daniel: you could handle URI variables differently

Kaz: we don't have to call all the examples "best practices"
... but we should improve all the example if possible

Ege: we should not use "actions" but should use "properties" for URI variables example

Kaz: if Ege or Zoltan could generate a better example, that's good
... also if Daniel has another example in his mind, that's also nice

Daniel: agree putting URI variables into "actions" is not good
... also wanted to mention another exampe

another example

Kaz: is anybody from you three interested in generating a PR for a better example?

Ege: can do it based Daniel's provided resource

Kaz: tx

<dape> example: https://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=439d4b804bc8187953eb36d2a8c26a02

Taki: tx
... so will assign it to Ege

Ege: sure

Zoltan: also we could mention how to handle multiple inputs
... but could create another issue about that

Taki: ok

Zoltan: that's related to the discussion on Scripting
... how to distinguish having one parameter from multiple ones

Koster: one parameter or multiple parameters within one object?

Zoltan: it's a bit misleading at the moment

Koster: would think about a best practice?

Zoltan: it's not well-described how to handle multiple parameters

Koster: could refer to OCF parameters

Kaz: so once Zoltan has create an issue about that, Koster can put a comment based on the OCF examples

Koster: ok

Taki: (puts a comment about the discussion so far)

Koster: Scripting API provides programmatic APIs

Zoltan: the algorithm should be compatible with various inputs
... would be good for somebody to look into the algorithm as well
... but this point should be clarified within the TD spec

Kaz: why don't we continue the discussion after Zoltan creates the issue itself :) ?

Zoltan: ok

Taki's comment to Issue 910

Issue 899

Issue 899

Ege: Matthias gave several points

Ege's comments

Ege: "Feedback on the proposals"

[[

Dynamic TDs (proposal 1): TDs should not be used as resources that change quickly or in a way that represent application state or data. This would mean that TDs cannot be cached and also would cause problems in proxying the TD/Thing.

]]

[[

Static TDs (proposal 2): This approach is against hypermedia where normally the hypermedia information should be generated dynamically by the Thing and the Consumer would follow it. In this proposal, all the relevant information to interact with the Thing in any state of the Thing needs to be communicated in advance. It could be very well the case that the possible interactions/operations depend on the state of the Thing.

]]

[[

Common to both approaches: The proposed new operation values will not be enough for more complex hypermedia cases.

]]

Ege: may need some powerful mechanism to handle state transition like SCXML

[[

There is no widely accepted hypermedia standard. That means that we can prescribe how it should be done with TDs. We can somehow support the existing implementations by Oracle and Mozilla but we do not have to guide the greenfield on the fact that hypermedia should be done like this.

]]

Zoltan: he had a comment to try something like CoRAL

Ege: need to support this?

Zoltan: do we want to generic one or some specific one for hypermedia control?
... if we are ok with specific one, I'm fine with this proposal
... but do we need a generic one?
... like CoRAL does for the Open API

Ege: we have implementations by Oracle and Mozilla so far

Zoltan: and concerns about actions?

Ege: right

Zoltan: we need use cases and then how to align with CoRAL

Ege: CoRAL itself is not supported so far

Zoltan: I'm not saying it should be supported but think there should be some kind of alignment

Koster: TD could describe a format for static resources
... and then invoke actions
... the format will be the same
... some hints on how to deal with it
... static information about underlining resources
... I have to create some example, though

Kaz: probably we should clarify some concrete use case and scenario including actual devices

Koster: we should try this during the plugfest
... but nobody has tried it yet

Daniel: we can show how it might work

Kaz: we should start with some initial scenario for this
... even though we can't try this during the plugfest next week
... Ege, maybe you can put your initial idea for the plugfest wiki or the use case repo
... and we could try this at the plugfest during TPAC

Ege: it would make more sense
... agree we need a concrete scenario for this discussion

Zoltan: would be better to have concrete PR based on the discussion
... maybe we could create a new issue for that purpose
... we need to move forward

Cristiano: would agree with periodic cleaning up for long-term issues
... to summarize the points
... if possible :)

Zoltan: good to clarify the important points
... but we don't have everybody here today
... so maybe a good topic for the f2f

Kaz: yeah
... let's put this as an agenda item for the f2f in 2 weeks
... and ask everybody to join it
... and try to create a PR so that we could look into this at the plugfest during TPAC

Koster: could generate a TD for that purpose
... how to deal with the location is a question

<Ege> https://github.com/w3c/wot-thing-description/pull/911

Kaz: yeah, so this topic is strongly related to the discovery topic
... so would be good to talk about this during the f2f

Taki's comment for Issue 899

PR 911

@@PR911 here

Ege: has just created a PR (PR911) for Issue 910

Issue 908

Issue 908

Taki: this is kind of new
... (default value for observable)

Issue 848

Issue 848

Ege: under specified within the TD spec

Zoltan: needs to be split out from the TD spec
... do we want to once remove it?
... or want to keep it within the spec?

Ege's latest comment

Zoltan: how the array is handled?

Ege: would describe how to specify contentType for array

Kaz: would it be possible for us to clarify what is expected behavior for each possible protocol?

Ege: would say yes

Koster: contentType is one possible requirement
... and uriVariables may be another

Ege: we could clarify it based on the coffee machine example

Kaz: btw, I have a naive question
... do we really need "readmultipleproperties" to cover our use cases?

Ege: that's my question as well

Koster: would use readmultipleproperties to get all the initial information at once

Ege: could use readallproperties for that purpose

Zoltan: yeah, most people use allmultipleproperties
... so my question is also if we really need readmultipleproperties

Cristiano: there're too many parameters for readmultipleproperties

Kaz: it seems to me it's too complicated to implement it and use it
... so my question is if we still need it

Zoltan: good topic for the f2f

Koster: and we need to clarify concrete use cases

Taki: agree this is a good topic for the f2f

Taki's comments for Issue 848

AOB?

Taki: anything about Binding?

Ege: nothing for today

Taki: ok
... will contact Sebastian about the Doodle poll for CoAP RDF discussion
... aob?

(none)

Taki: ttyl then

[adjourned]