W3C

- DRAFT -

WoT IG - TF-AP

13 Jan 2016

Agenda

See also: IRC log

Attendees

Present
Johannes_Hund, Joerg_Heuet, Matthias_Kovatsch, Sebastian_Kaebisch, Daniel_Peintner, Dave_Raggett, Toru_Kawaguchi, Louay_Bassbouss, Claes_Nilsson, Ari_Keraenen, Arne_Broering, Frank_Reusch, Michael_Koster, Taki_Kamiya, Yingying_Chen, Kaz_Ashimura, Carsten_Bormann, Katsuyoshi_Naka, Dan_Romascanu
Regrets
Chair
Johannes
Scribe
dsr

Contents


<scribe> scribenick: dsr

Dave explains why we have had to change the call details.

Johannes runs through the agenda https://lists.w3.org/Archives/Public/public-wot-ig/2016Jan/0011.html

Any additions to the agenda? [no]

Kaz: some of us have been unable to get our payments through and have asked Soumya for help.

Dave: Soumya is working with a colleague to resolve this, and if necessary we can resolve this some otherway onsite during the meeting.

Topics/contributions for F2F

Johannes: Are there any contributions that you can share with us in respect to the face to face agenda?
... You can also send detail on the mailing list, and we will also see what we can for remote participation.

Plugfest howtos and preparation

<kaz> Nice f2f wiki

Johannes: that page includes a collection of links on how-to’s etc.
... There are several topics: security, registry & discovery, scripting and HATEOAS.
... Louay’s proposal covers scripting APIs
... In respect to HATEAOS there is a proposal to have a joint plugFest and plugREST event
... any questions or feedback?

Dave: I am working with Tibor Pardi on a remote demo on security in cooperation with Oliver - this is for the NodeJS web of things server project we started last year.

Johannes: please fill out the plugfest participants table

Dave: I hope we can do so on Friday - Tibor has also been busy recently

Review proposed TF-AP breakout topics

Johannes: I am collecting topics for break outs - we have some initial ideas in the agenda

<kaz> TF AP topics

The draft agenda:

<inserted> [[

Finalizing Tech landscape

WoS scripting APIs

    General design decisions, opinionated base principles

    APIs for registering and discovery (joint discussion with DI?)

    Security considerations and security handling in APIs (joint with SP)

    APIs for the physical thing interaction a.k.a. “southbound API” (johnnyfive-like vs. data-driven/thing-driven)

Clarification / formulation of the relevant WG item

Protocol bindings

    Definition of the interface nature between W3C and protocol SDOs

    IRTF T2T: WoT over RESTful protocols (HTTP, CoAP)

    Invited experts from others SDOs, such as XSF or BT SIG

    Clarification / formulation of the relevant WG item

Plugfest wrap-up

    Findings

     Next steps

AOB & next steps for TF-AP

<inserted> ]]

Johannes briefly introduces each of the agenda items

Johannes notes that there will be an XMPP standard foundation summit will occur on the same day

<jhund> parallel meeting: XMP Standards Foundation Summitnin Brussels

we will see if it is possible to have a remote joint session

<michael> OIC are also having the member meeting in Bangkok

There is also a parallel OIC meeting. We weren’t able to get someone from OIC for this face to face.

<michael> 1/24 - 1/29

<michael> I will be in Bangkok

Johannes: we will also discuss implementation feedback from the plugfest etc. and a roadmap for what we want to cover before the April face to face.

Johannes invites people to add new agenda items to the wiki as appropriate

Working group items “API” and “protocol bindings”

<jhund> https://www.w3.org/WoT/IG/wiki/Proposals_for_WoT_WG_work_items

Johannes discusses the proposed work items for the Working Group that are on the wiki page above

It would be very good to have other people commenting and adding their support etc.

we want to clarify each of the proposed work items with a very clear scope.

This includes the expected deliverable(s) for each item.

If you cannot attend the face to face we still want to hear from you, either on the wiki or via email

Johannes strongly encourages participation from many voices on the working group charter

He points to the comments in the wiki on the scripting API related deliverables

<kaz> Scripting API

Dave: Given that different programming languages will have different API design conventions, we need to clarify our aims here as a single API definition will have some assumptions in respect to design conventions.

Johannes: we should try to keep it as portable as possible

Dave: suggest a two level approach, a functional definition independent of design conventions and normative instantiations for specific design conventions, e.g. promises and JavaScript

Johannes: we could also consider a low level basic API that can be used to implement high level APIs for specific contexts

Carsten: is there a narrow waist (thin part) in the stack of layers, and is this a programming API or is it a web API?

I would like us to focus on Web APIs

Johannes: an interesting point, I am not sure it is one or the other

Carsten: with web APIs for the narrow waist, we still get interoperability

Johannes: we need APIs at the scripting level for generality

Carsten: many of these things are hard to discuss in the abstract, we need concrete examples

Johannes: agreed

Daniel: I wanted to come back to the term Web API, for me that is similar to WebIDL, and that is where I want to focus on

Carsten: there is active discussion on how to describe Web APIs with several formats vying for this.

<michael> RAML, RESTdesc, Hydra,

<michael> HAL

In the T2TRG we’ve been using HAL as one way to describe these interfaces, the jury is still out there

Dave: I am interested in APIs at the application level that respects the decoupling protocols, message formats and communications patterns - this is a critical point for the generality of the web of things as a platform of platforms. We can have APIs for other layers but these should be a separate discussion

Carsten: I don’t think this is possible as it will be necessary to expose some of the low layer details

Dave: application code will have access to metadata e.g. communications and security metadata

Johannes summarises the discussion

One position is to provide protocol layer API, another is to provide higher level APIs

Michael: it isn’t a matter of either-or, it is more about APIs at different asbtraction layers, we need both

Dave: agrees

Carsten: APIs need to match the design abstractions for a protcol. If you avoid that you are likely to have a leaky mechanism that leaks info across layers

Dave: I agree with Carsten that to proceed effectively, we need some concrete examples

Louay: regarding the abstraction level, we already have that from thing descriptions (properties, actions and events). This was an input to the API I proposed

Johannes: we can proceed from the thing model, and we can proceed from the protocol layer

We don’t need either-or rather we need to clariify the use cases for each API

Louay: the W3C 2nd screen API is already an abstract API with at least 2 implementations.

This is one example of an abstract API that runs on top of different protocols

Michael: I have been abstracting REST APIs, and this provides a consistent approach across protocols

Carsten: I completely agrees with Michael, but rather it works with a shim protocol on top of the full protocols, and we should be careful in what we say

Michael: you’re right I was focusing on hypertext
... but these protocols are just transport layer and doesn’t provide the application layer abstraction

Johannes: we should bring in the people who have been using specific protocols, e.g. OIC who have worked on REST over XMPP, this wasn’t accepted by all though. I think we need to keep the question of app level vs protocol evel

<michael> REST over XMPP was the OIC discussion

Dave: presents abstract layer diagram and invites us to be careful to identify which layers we dealing with and to find a set of use cases the stress the solutions

Carsten: some of the protocols span layers, e.g. XMPP, treating HTTP as just a transport leads you down the SOAP path

Kaz: some discussion on OIC in Sapporo, and we should investigate OIC’s approach further

UPnP consortium has merged their work into OIC, and we now have a liaison with OIC as a consequence. also we got some data model proposal from them. (will forward it to the group later)

Dave: unfortunately we couldn’t get someone from OIC for the January F2F, but hope to do so in future either in a telecon or the April F2F

<michael> I will be working on OIC data models and protocols but I'm not up to speed yet

Johannes: yes there is an OIC meeting at the same time …
... industrial alliances may be focusing on a solution for a particular problem space, where as we need to find commonalities across problem spaces

I agree that we need to talk to different alliances, but we won’t be picking one, rather finding a way to define an abstraction that enables interoperability across platforms.

Is that good enough for today?

Dave: sounds good to me, let’s take this forward to the face to face

<kaz> +1

Johannes: we will need to work on the technology landscape - there is a document skeleton on GitHub and will try to move this forward by the face to face.

We had a good discussion with lots of energy! My thanks to everyone.

Please don’t forget to register for the face to face (deadline is this Friday) we will look into the problems with the payment mechanism. If you have an implementation for the plugfest please add yourself to the participant’s table.

Tomorrow there is will be full IG telecon in preparation for the F2F

scribe: end of meeting.

p.s. the slide Dave showed is slide 18 in http://www.w3.org/2016/01/web-of-things.pdf

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/01/13 15:07:10 $