See also: IRC log
<yingying> scribe: yingying
Johanes: ask people to introduce
themselves on the webEx dailling in.
... We will start the breakout.
slides->https://www.w3.org/WoT/IG/wiki/images/e/e4/W3c-wot-tpac2015_t2trg-rest-iot-00.pdf
Ari: introduces the RESTful design
Ari shows the goal of the document, the background and the status.
Ari: this is the very starting
point of discussion. Your contributions are welcome.
... comments on terms are welcome.
... if you have already read the document? is there anything we
need to discuss more?
... components in system: client and server can change the
role.
... application state: session state with client only, resource
state.
Nilsson: could you explain the resource state?
Ari: I would appreciate your opinion on it.
@@@1: sometime it's difficult to know the state of client.
Ari: Yes, especially when client /server changes the role.
Joerg: it's not easy to clarify the session state and resource state. How are they related to application state.
Ari: concrete use case would be
appreciated.
... we will discuss it in IRTF meeting.
Ari explains UIR.
Johannes: Do you have an example that only the scheme is different while other parts are the same?
Ari: @@@@@@1
@@@2: there are various contexts that need to take into account.
Dave: how would the upper level
abstraction? is there any consideration?
... why should we use it for web of things context?
Ari: safe/Idempotent
methods.
... simplest one is GET.
... POST method: not safe nor idempotent.
... PUT method: idempotent.
... DELETE method
... comments.
Johannes: in the plugfest, we use DELETE to cancel the execution. Why do you guy do it? We use it.
Ari: modifying properties of resources with methods.
Nilsson: confused about PUT and POST. example please.
Dave: PUSH and PATCH
Ari: PUT or POST is not a clear cut.
Johannes: example of light bulb. set on or off, use PUT; set fading, suggest POST.
Louay: We have actions on services and resources at the same time. How to handle it?
Ari: Actuation is less obvious at the moment.
Johannes: request Ari to send out the topics for further discussion in the mailing list.
->https://www.w3.org/WoT/IG/wiki/Mapping_of_tech_landscape_to_IoT_approaches
Johannes: request for volunteers to fill in the landscape mapping.
Claes: volunteer for AllSeen
Louay: @@@@@@@
@@3: AIOTI1
s/ @@3: @@@@@@@1//
<inserted> kajimoto: volunteer for Echonet
people volunteer to fill in the table.
Johannes: will do a temporary
freeze on wiki and transfer materials to GitHub.
... explains the table colunms
<ryuichi> volunteer for oneM2M
Joerg: suggest to put some criteria for each aspects.
Dave: suggest to add one free column when not feed into.
Johannes: hope to fill in the whole table by end of the year.
-> https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Documents_and_deliverables
<stakagi> At least, multiple parties thought that the sensor or Low Level Device API for web browser and were related to WoT, and have proposed it yesterday.
<stakagi> I think that WoT IG should search for it within a certain framework (TF etc.).
Johannes: The purpose of the
topic is that we need to make a decision on which documents we
would like to actively maintain.
... 1st doc is architecture model. How should we proceed with
this document?
... should we put it alive or just archive it?
<inserted> scribenick: kaz
ryuichi: thinking about concrete/comprehensive implementation model is good
claes: architecture?
johannes: we don't have architecture as a target in the charter
joerg: actually, there is some description on architecture within the charter :)
-> http://www.w3.org/2014/12/wot-ig-charter.html#deliverables WoT IG Charter
<yingying> Johannes: what is the tooling for architeture docs?
<yingying> Dave:there is tooling for specification.
<yingying> Johannes: How to move forward?
(some discussion on how to deal with the document)
johannes: would start a document
with this picture and Kajimoto-san's implementation model
... any volunteer?
kajimoto: will do
johannes: you can ask people for
help
... gh-pages branch is directly accessible as an HTML
... next, we have Web Thing API proposal from COMPOSE
claes: official input to W3C
johannes: meaning a submission?
claes: yes
johannes: this link (to COMPOSE
proposal) links to GitHub now
... and will be the one for that submission in the future
... and add an entry for COMPOSE to the Conso table
... next, FOKUS
... there is a space on GitHub
... make sense to have a place on the APIs
... (w3c/wot/TF-AP/thing-api on GitHub)
louay: landscape lists something
like presentation api
... how to apply those apis to wot?
... can put all the examples
johannes: great
... accessing APIs should also be added to the landscape
doc?
louay: yes
johannes: where to put all the
info?
... should create a place on GitHub now?
... what's the good method?
joerg: a possibility is putting all the deliverables together
johannes: until we reach the final stage (=can ask people to refer to the doc), simpler approach would be better
louay: WebIDL, security model,
user interaction, etc.
... all the discussions should go into one document
johannes: yes, but what would be the appropriate structure?
joerg: the closest deliverable is a guideline in the Charter
johannes: need an action
... next, Interaction model and Protocol mappings defined for
the Plugfest
joerg: discussion on TD, DI, AP,
SP
... what would be the best structure to handle this?
... separate structure would be good
... physically could be one document
johannes: so we should go for
having two docs?
... one for landscape guideline to provide a single point of
entry
... do we have somebody who would provide an idea on the
structure?
dsr: can have a brainstorming discussion now :)
johannes: merging all the three
points (proposal for client-side scripting API, Proposed
document template for interaction primitives and their mapping
to APIs and Protocols, Interaction model and Protocol mappings
defined for the WpT Plugfest)
... what would be the best structure?
-> https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Documents_and_deliverables TF-AP wiki
kaz: how about simply putting all together with having a section for each?
johannes: don't have an answer at
the moment...
... would wrap-up the discussion
... 1. definition of an architecture model
... 2. Landscaping of relevant technologies
... 3. Web Thing API proposal from COMPOSE
<inserted> ... 4. new respec doc including three points (client-side scripting API, interaction primitives and mapping to APIs/Protocols, Interaction model/Protocol mapping for Plugfest)
louay: imagine having a sensor
for humidity and temperature and another sensor only for
temperature
... need different protocols for each
johannes: other comments?
danielp: how we could model
device updates
... thing description should have that capability
johannes: set of actions and
properties which could be handled by the native level
... and how to handle thing description changes
danielP: as the starting point, we can record the issues
johannes: ok
... we'll look into more deeper detail on actions and
properties
... may need multiple layers or hierarchy
louay: we need some
definition
... how should I describe temperature sensor?
... need some ontology?
johannes: one option is describe within TD, another is accessible URI
louay: we can have more
interoperability
... e.g., for DLNA, there is a specific mechanism for the
description
johannes: this discussion should
go to TF-TD
... another point is how things relates to other things
... consider this room is a "thing"
... this topic is something to be handled by TF-TD
... and Daniel's point?
... changes over time
... we didn't handle this so far
... some of the description could be rendered dynamically
... really interesting topic
... maybe we could add an implication about that
... possible changes over time
... any more points?
... how to deal with long-running/short-running?
... actions for input/output
... more than executions for one action
... like the COMPOSE model
... wonder if we would extend our model
... e.g., normally this schedule
... but on holidays use this schedule
... huge tree of resources
... if we have 50 parameters for heating system at home, that
doesn't scale for a factory
... any more experience?
dsr: cyclic dependencies
... server needed to have a queue
johannes: might want to elaborate what a proxy is like
dsr: shows his slides
... definition of "Things"
... Things stand for physical or abstract entities
... Things as software objects in the application programs
execution environment
... There are many potential protocols which will depend upon
the context
johannes: how to create the "abstraction"?
(some discussion)
dsr: shows the picture of
"Distributed Web of Things"
... Question of Relativity
... Some Requirements
... create a thing from its metadata and an
implementation
... Communication Patterns
... tree proxy
... Simple Message Exchange
... can be layered on top of transport protocols
johannes: is there any atomic approach?
dsr: Protocol Bindings
johannes: clear idea on what's
comparable?
... communication patterns?
... should we include those topics?
... looking at the time
... we're pretty much ahead of time
... ari, have you sent out your points?
ari: yes, done
johannes: skimms what we did in
the morning
... deliverables defined in the Charter
... quite a lot topics
... thanks for scribing
... one-hour break and breakout report at 1:30
... will do TF-AP report myself
<dsr> WG items proposals at https://www.w3.org/WoT/IG/wiki/Proposals_for_WoT_WG_work_items
<dsr> draft charter at https://github.com/w3c/wot/blob/master/WG/charter.md