<yingying> scribe: yingying

Johanes: ask people to introduce themselves on the webEx dailling in.
... We will start the breakout.

RESTful Design for Internet of Things Systems (Ari)

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.

Tech landscape, next steps and milestones

->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.

Document status

-> 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)

Implementer's experiences and feedback

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