<mlagally> scribenick: mlagally

Agenda

Sebastian: Approval of last minutes

<kaz> Jan-24 minutes

(Sebastian walks through the agenda)

Review of previous minutes

Sebastian: let's review agenda from last meeting (Jan 24th)

<kaz> Jan-24 minutes

(Sebastian walks through the minutes, does a recap)

Sebastian: any objections to go public?
... hearing none, they are approved

Proposed Recommendation

Sebastian: kaz, what's the process, in one month it will be REC.
... we have some highlighting issues in the examples, can we do some editorial changes?

Kaz: this is under AC review, all AC reps are asked to review this as well as the architecture spec
... people are requested to provide comments on the mailing list
... cannot add normative changes to those specs any more
... however editorial changes can still be done

Sebastian: We have highlighting issues, perhaps we have no longer valid JSON, we need to find out the reason

Daniel: there was an issue raised by respec developers that some parts are breaking, there's a PR for this (872)
... the preview looks a bit weird, there are respec issues
... (Shows Example 1, which is broken)

<kaz> PR 872

Daniel: Kaz, can we keep the old version
... the filer of the issue presented the respec changes at TPAC

Lagally: Kaz, do we have the same problem in the Architecture spec?

Kaz: I can look into this issue and the PR. However, we don't have to care about problems with respec but can concentrate on the static version for our next publication as RECs

Sebastian: perhaps we fix the highlighting manually
... btw, could you remind me of the URL of the AC vote?

Kaz: the announcement about the AC vote was sent out to the AC members list, and it includes the URL of the AC review form.

<inserted> AC announcement (Member-only)

New Issue (Daniel)

<sebastian> Issue 877

Daniel: In the scripting API we would like to specify how people can indicate which binding to chose, if there are multiple options
... currently we select from top to bottom
... the TD does not offer a way to specify

Lagally: what does preference exactly mean, hard or soft preference?

Daniel: it is just a soft preference

Zoltan: if we state the order as a preference, this is enough

Daniel: technically there's no change required, there is no change required
... one statement in the spec is enough

Sebastian: is there a use case?
... when we started, we had a numbering for protocol picking. We removed it because we found no real use case
... the client can pick his preferred protocol
... if a server offers multiple protocols, it is up to the client

Zoltan: this is an implementation thing where this choice has to be made

Lagally: if we have multiple TDs with different orders, they offer the same contract and should be functionally equivalent

Sebastian: Let's consider an example: if I can offer an observe mechanism vs. long poll, it is more efficient

Ege: we can also think outside protocols, if the content type is different
... what happens if alternatives are not equivalent ?
... for longpoll and observe there could be different forms depending on the op

Koster: if a client knows what op to do, it picks the form for that op
... ordering would work, but there's also protocol negotiation pattern in HTTP
... queue(?) values, I never used them
... relying on a serialisation format, you may have a different order based on a serialisation format
... what would people actually use?
... does the server always really know the best option?
... the client can always override
... would that really be used?

Taki: in most cases, the server side does not have a preference
... if there are multiple choices from the server, there is no preference. Client needs to make the decision.

Lagally: I can see one use case: if there is a preferred higher security on certain operations, the preference would be useful

Issue: 302

Sebastian: actions can be asked about the status (still runing, finished)

<inserted> Issue 302

Sebastian: also actions can be deleted
... question is whether to introduce it in the TD
... there's a long discussion, Ege can you give a short review of the comments?

<ege> https://github.com/w3c/wot-binding-templates/issues/2

Ege: The issue is very old, it was the 2nd issue in the binding template issues
... request can start an action, before it actually is finished, e.g. fading a light, closing blinds, moving a robot to a different location
... Mozilla stated, that this is currently not supported in the TD
... In their case the response contains hypermedia links to query status or cancel the operation
... how can we describe such a mechanism in the TD, there's a proposal by Victor
... output returns an object with href and status
... href contains an @type annotation for managing the actions
... urivariables provide the information about links to these operations.
... there are operations "cancel" and "query"
... I commented that there are actions that never stop, e.g. a conveyor belt
... that continues running until it is stopped
... a stop movement can impact all other onging actions, there are real use cases
... some TDs modeled this via properties
... this should be an action

Zoltan: such action could return a thing, this has beed discussed several times and there were objections

Lagally: We should not impose a new format on existing implementations, i.e. we need to describe existing systems
... Oracle already has a deplyoed System, Mozilla too, we cannot ask for a change of the implementation

Koster: if we can come up with a pattern that returns a TD, a different content type,, or some other payload content
... we must be able to describe an existing system

<sebastian> https://github.com/w3c/wot-thing-description/issues/302

Sebastian: hypermedia is not really standardized, there's no common way for responses, this is open for any systems
... In HTTP and CoAP you have location in the header, I'm not aware if people actually use that
... this is a very specific technique for these protocols
... there may be very different other ways
... i'm not sure we are able to describe this protocol behavior in the TD

Koster: We had some discussion around protocol bindings, we cannot describe all mechanisms, however can describe a state machine
... the client can follow that, the TD does not specify all implementation patterns
... can we design an abstraction for commonalities?
... we have to able to adapt, there was a discussion in the architecture group
... we have to support all the ops, we may have optional ops

Lagally: This comes back to interoperability vs. describing all possible existing devices
... this comes down to having a profile with a minimum set of guarantees between client and thing

Koster: I agree, some TDs may have operations that are optional
... maybe we can trade off by having different TDs with different OPs, like HTTP vs CoAP, the client may know what to do based on the protocol

Klaus: For encoding in TD, do we assume knowledge about behavior of the thing
... if yes, you just include the name of the pattern, otherwise you need a detailed language in the TD
... Otherwise you have to describe the hypermedia state machine
... This pattern of asynchronous actions is very relevant
... would like to have support in the TD
... we have physical actions and protocol actions, we start thinking with 1:1 mapping, however going forward an app may use one action to affect multiple ongoing actions

Sebastian: do we want to teach the clients what is hypermedia or is it just a singaling that hypermedia is used
... TDs should support both, i.e. indicate that hypermedia is used and to describe the pattern
... Mozilla has a specific pattern, however they do not specify it in the TD

Koster: there's an entry point in the TD, there could be a content format to describe the details
... that would be interoperable
... Klaus can show us some ideas for the content format
... protocol bindings get much easier with LWM2M
... client knows what to do

Sebastian: Does LWM2M use Hypermedia?

Koster: they use links, but no dynamic hypermedia

Sebastian: would lie to see examples of impelemtations, e.g. Oracle

ML: I will add more information to the issue

Sebastian: we should have implementatinos on the table
... we have this idea from Lagally about the profile, default assumptions about hypermedia

Lagally: does it make sense to look into Mindsphere?

Sebastian: I will check

Klaus: In T2TRG we have areference device(coffee machine) where you can make coffee orders. We're using hypermedia

Sebastian: Klaus, can you please provide more info?

Klaus: yes

Sebastian: these devices (Oracle, Mindsphere, Mozilla, Coffee Machine) should also be considered for the Helsinki plugfest

Kaz: We should consider this in the plugfest call as well

Sebastian: We need a draft proposal

Kaz: starting with a survey of existing implementations is good

Taki: In the proposal there was query and cancel, when action is in process we may not be able to cancel
... best we can do is stop the action, do something else. We may not be able to go back to the original state

Sebastian: Are you asking for a clear definition of cancel?

Taki: yes

Kaz: maybe we can have a specific session with session rollback capability, but that might be too advanced. so I'd agree with Sebastian that we should start with initial survey and proposals

TD Payload Pattern

Sebastian's slides

<kaz> scribenick: ege

Sebastian: motivation is that IoT systems already come with a message pattern
... ikea comes with the payload structure shown in the slide with these integers denoting different meanings

<klaus> https://github.com/OpenMobileAlliance/lwm2m-registry/blob/test/3311.xml

klaus: these integer values come from LwM2M

Koster: I also have TDs like that
... OCF has the same things as well

Sebastian: it looks like this in the scripting level
... would be better if we can have more human readable in the scripting level
... defining message template or application paramaters which are passed to the scripting level
... we can also define them in a global way

Koster: I have used the tag defined in iot schema

Sebastian: how do you do the parameters in the programming level?

Koster: I use the full URIs defined in iotschema
... I have something that can bring them up as a flat JSON object
... also using it in the global level?

Ege: so you would tag an interaction affordance with e.g. MessageTemplate and you would be able to refer to that

Lagally: what if you don't have the tags?

Sebastian: you would use it just as a normal TD

Koster: different platforms can have different meanings of transition time for example

Sebastian: Even if we annotate, the payload does not change
... so only when programming it takes effect
... using semantic annotations would be nice here

Lagally: I am wondering what the client should do

Sebastian: I am interested in approach of mk
... @type can be used for any protocol etc.

<kaz> [adjourned]