<scribe> scribenick: kaz
<Ege> https://github.com/w3c/wot-thing-description/issues/848
Ege: would like to talk about the above issue if time permits
Taki: anything to be fixed?
(none)
Taki: approved
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
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
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
Taki: issue raised by Zoltan
Zoltan: just wondering about the best
practices for TDs
... actions using URI variables
... in 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
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
Ege: Matthias gave several points
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
@@PR911 here
Ege: has just created a PR (PR911) for Issue 910
Taki: this is kind of new
... (default value for observable)
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?
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: 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]