Johannes: [reviewing the agenda]
... Are there any additions, comments for this agenda?

<jhund_> https://github.com/w3c/wot/wiki/Architecture-Model

Francois: not sure if part of last topic on the agenda, want to better understand the TF outcome for the WoT Label document

Johannes: part of the last topic agenda

Architecture model

Johannes: [looking at the architecture model]
... The diagrams can be edited as text, in PlantUML format
... Wondering if the tooling is acceptable, and the content itself.
... How does such an event look like, how does it map to a physical device and how implementation on a legacy device would work.
... Continuation to discussions at the F2F meeting
... It describes how things in the WoT interact
... Any question?

<jhund_> https://github.com/w3c/wot/wiki/Architecture-Model

Johannes: all comments are welcome on the mailing-list.

Generic Sensor API

<jhund_> https://github.com/w3c/sensors/issues/18

Johannes: As short intro, Claes posted a comment on the GitHub page of the Sensors group. I asked Tobie to join this meeting.
... Thanks for joining us, Tobie.
... Can you give us a short introduction of the Generic Sensors API?

Tobie: This is actually work going on in the Devices API Working Group, started a long time ago by Rick Waldron, with a view to having a consistent model to design sensors API.
... The goal is to have a generic API on top of which more concrete sensors API can be defined.
... Starting with Proximity APIs, temperature, and broadening a bit with e.g. geolocation
... Some things you are dealing with fit here as well.
... We are trying to find the right primitives and understand the performance constraints that are existing to understand how things fit together.
... It's a good time to discuss since there are obvious places where your and our work fit together.
... The discussion we had on GitHub was very productive for me. It allowed me to better understand the needs that you may have.
... In the updated version of the editors draft, we'll use a basic API around the EventTarget interface defined in the WhatWG spec
... Then you would have subclasses for APIs such as temperature sensors.
... The conclusion I arrived to in issue #18 was that the DAP WG needs to focus on sensors and I do not think it makes sense to integrate broader things such as the ones you're dealing with.
... I would like to hear how the generic sensors API addresses some of your use cases and how you can work from them to extend the scope

Vlad: Do you have a more abstract sensor model?

Tobie: I'm working on a first draft of the spec. There has been discussion in the mailing-list. I don't have anything better to share right now than what you see.
... The goal is to have a very clear basic model and make it clear how to extend it.
... Consistent common syntax for using sensors-based APIs of the kind that you already have in the device. It hasn't properly thought out to deal with remote sensors for real, or to enable really low-level sensors like you could imagine on Arduino-like boards. Neither of those are my area of expertise, so still learning here.

Vlad: So it's a generic model, not necessarily a JS API?

Tobie: Kind of both. A generic JS. You'd have "new Sensor". You would pass the address of a source, a function that can process the events. Raw API in short.
... Also a spec that would help spec editors dealing with, say, a Proximity sensor API write the spec.

Johannes: How do you foresee extensibility? Maybe we'll have radiation sensors in the future?

Tobie: The idea would be that you would basically do something like what I'm going to write on IRC

<tobie> RadiatioactivitySensor : Sensor

Tobie: You would extend the Sensor interface and then decide where it fits, for instance part of window.
... It depends on whether you want to expose that sensor inside of the browser.
... Another useful way would be to have a way to write some JavaScript that does the same thing, rather than forcing the browser to support it natively.
... Permission issues would arise, of course.

Johannes: So subclass the Sensor interface?

Tobie: Yes.
... The other goal of the spec would be to enable in low-level environment (think Arduino) the use of a third-party library that would come with a sensor that you plug in. That would allow you to play with the sensor without having to wait for the browser to support that.
... Longer-term goal.

Johannes: What would you see as best practices when we design the APIs for the Web of Things?

Tobie: Two of the key concerns that we have with the Web of Things:
... 1. The WoT does not only target sensors so I only have a partial answer to the question.
... How do you handle actuators? servers? things that do a mix of these?

Vlad: Our view is that everything is a Web Thing, they just have different capabilities.
... That's our basic assumption
... Described in terms of events, properties, actions.
... Not making differences allows you to have a common basis. Then you can add additional information.
... It's an important way to get everything on the same page

Tobie: OK, now at least I have an idea as to what the goal is. The question is, technically, how would you want to do it?
... We have time constraints in the WG (and myself with my client). I do not know whether the WoT timeframe and the DAP timeframe are aligned enough that we can wait for your group to come up with something before we can move forward.

Vlad: We also have a short timeframe
... I uploaded a draft version on GitHub but our plan is to work on a final version of the document in the next few days.

<Vlad> https://github.com/w3c/wot/tree/master/TF-AP

Vlad: The PDF at the root level explains our current thinking. There will be quite a few changes but it captures our views on that.
... It defines a JSON format since it's easy to use in JavaScript.
... get WebThing example, you'll get a description, then you click on properties and you get descriptions, then retrieve actions.

<Vlad> https://github.com/w3c/wot/blob/master/TF-AP/JSON%20Payloads/actions/actionType/get-action-type-example.json

Vlad: Examples show the payload to describe an action. Quite similar to what you have.
... The example I pasted is a description of a reboot command with 3 parameters.
... For me, those are the points where the two projects are touching.
... By the end of the document, we'll provide a shorter and sweeter document.
... The goal is to have a basic model.

Tobie: This document touches on the second point I have
... 2. what part should be defined in the generic sensors API and what part should be defined elsewhere. This is critical to the work you're doing and maybe less so to the work I am doing at this point.

Vlad: By lifecycle, do you mean how do I discover things? Sensors appearing, disappearing?

Tobie: Pretty much. My understanding from what I've researched so far is that for pretty much all the use cases we have so far, which are around exposing sensors that are already part of the device, the information is already available when we want to create a Sensor object.
... None of the descriptions needs to be in the API we want to expose.
... There is some area around it where we may want to know more, but not a lot we don't know initially.
... What you do is more or less out of scope to the work I'm doing, and that's actually a good way to split the work.

Vlad: I understand your point of focus.
... It would be good to have a common way to understand sensors and data streams.
... Device with events, properties, actions, very high-level data-oriented way to describing things.
... Or you can think in terms of device that has sensors and actuators.
... Taking the example of a camera, contains sensors and actuators. Do you want to expose the camera as a thing concept or do you want to expose sensors that can e.g. produce JPEG and actuators that can run a flash

Tobie: I've been struggling with this as well.
... so glad to have this discussion :)

Vlad: I don't think that we have an answer to that so far.
... Having something that is called a sensor could be a useful abstraction to know that it's something that you can read value from. You might want to turn on/off a sensor, does that mean it's an actuator as well? Etc.

Tobie: Yes, you could have a sensor to get the picture or video, and an actuator to turn the sensor on/off.

Vlad: I agree. We have been thinking about things in terms of mixing sensors and actuators.
... We could think of sensors and actuators as things
... We're thinking about things that are gateways to other things.
... That provides extensibility to map a gateway to a mobile phone that contains sensors and actuators, or a Raspberry PI that is alike.

Tobie: It gives me a much better understanding as to the way you're thinking about the problem space, which is... a good thing :)
... Can you actually reuse that model when we get to the JavaScript part? Can you reuse the primitives when you want to represent these objects in the browser

Johannes: Right, that's my question as well. Looking at how the protocols are looking and how to expose things to the developer.
... It would be very good if we can try to align with the proposal that you have.
... Maybe we can make suggestions that can be worthwhile to look at.

Tobie: Good next step would be for you to read the initial draft spec when it's out.

<jhund_> https://github.com/w3c/wot/blob/master/TF-AP/Example_sketch.md

Tobie: Then the other step is to look at the lifecycle part (which I call the "handshake"), which is clearly out of scope for the spec I'm working on but in scope of your work to see how the discovery phase can work.
... I'll check with my client, but should be able to join and contribute on the mailing-list

Johannes: Great, thanks for the discussion!

Discussion on primitives for entities/interactions/payloads

Johannes: We already stepped into that topic during the previous discussion
... Now it's really about merging the different contributions
... [sound chopped]
... Basic model of explaining the mapping against Web protocols while keeping in mind that there are other protocols in use such as CoAP
... There was discussion to merge the document into a Markdown document
... or as an HTML document to be an official document

Francois: [making process point about IG not supposed to work on technical specs, wonders about TF outcome for this document, suggests W3C submission]

Johannes: Our intention was to work on something concrete to have something tangible to discuss.
... The deliverables of the IG should be guidelines for deliverables.

Francois: Note the W3C submission does not prevent you to use the document for other purpose. Some member(s) would need to sign the submission, making a few patent commitments. That would be a great way to shake things up with a concrete proposal. Just cannot be an IG-stamped document.

Vlad: I agree. The action on my side is to have a shorter and more crispy document by the end of the week.
... By mid next week, we could have something in good shape for a submission.

Johannes: so an action on Vlad to make it more submission-like. Share it on the mailing-list as well, I think that would be useful.
... For being clear on the outcome here, we will start merging this document into the markdown one.

Vlad: We're planning a similar document as the one that already exists. Removing blah-blah here and there. Then we can convert it to HTML, except if we have some way to convert it automatically from markdown to HTML

Francois: There is, indeed, thanks to Tobie adding support for markdown in ReSpec
... You would continue to write the document in markdown afterwards.

Johannes: The roadmap would then be: create a document that merges these two inputs, directly editable on GitHub, then use a tool to convert that to a submission

Vlad: my suggestion is that I take your input and merge it on the Google doc since we'll be working on that document in the next few days, then convert it once and for all afterwards.

Johannes: My main point would be that we have something editable in Github in some point in time.

Vlad: Latest end of next week!

[discussion on spec Markdown / HTML]

[Tobie reports that markdown cannot be a complete stand-alone solution at it needs ReSpec to process WebIDL and other structures. Useful not to have markup tags for paragraphs and lists, etc. Idea is to look at the examples and see if that matches our needs]

Johannes: next meeting next week

[call adjourned]