<yingying> scribe: Daniel

<yingying> scribenick: dape

updates for CP w.r.t to TD

SK: 1. updates for CP w.r.t to TD
... discussed points are already integrated
... e.g. media-types
... one container for Property, Action, and Event using @type
... local endpoint information can be described also
... e.g, what is Uri, what media-type

<sebastian> http://w3c.github.io/wot/current-practices/wot-practices.html#thing-description

SK: no change for integrating other contexts.... still possible to use other @types's
... global endpoints are possible also
... idea is to have a global base uri... locally one can define relative path OR override some information
... e.g., switch from http to coap

DP: for next PlugFest, do we plan to "test" complex type defintitions

SK: lets postpone discussion when we discuss PlugFest scenarios
... Internal Siemens feedback, especially from Matthias (who raised issue #287)
... re-use common vocabulary

<yingying> issue 287

SK: endpoints --> link
... uri --> href

TK: Any reason why we have to follow html example
... endpoints sounds more appropriate

SK: MK just likes to re-use existing vocabulary
... Dave also mentions that we should try to make TD Web developer friendly

DP: be cautious about plural form.. link, just singular ?

SK: TK and DP, please raise/comment issue on github
... be aware that CP document might slightly change the upcoming days

Naka: href is still in example 3
... will confuse people

SK: Agree
... idea is global vs. local information
... should try to simplify it
... NakaSan, can you raise this as issue?

Naka: OK

SK: Another issue from Alex Owen #268
... proposed td class field
... references to CSS files
... I am proposing to use @type
... not sure if we really need that new field
... There are some more TD issues... no urgent ones anymore

Stick with JSON-LD or change the format to JSON

SK: Dave worked on that topic
... think we need a more principal discussion
... TD should be independent to programming languages
... Shows slide (WoT TD Basic Assumption)
... Servient1 in JavaScript
... Servient2 in C++
... TD format independent
... JS can wrap JSON
... C++ might map to structs
... focus of TD is to be independent

Uday: strongly support your argument
... want to be an abstraction layer
... try to be as neutral as possible

DP: Not sure about consequences (JSON vs JSON-LD)

SK: Dave proposes to have TD similar to Web Developer application layer
... mapping to JS objects

DP: Also would like to mention that JSON-LD is a set standard and tools are built around this
... people are used to this tools

SK: I would like to differentiate between the abstract TD format and the actual applications working with TDs
... TDs may become complex... people might tend to use tools for creating TDs
... humans can still edit it... but might not be sensible for complex scenarios

TK: IF majority of languages is JS then i would go with JSON
... since we don't know yet a more neutral format is better

SK: Dave will present his idea in the afternoon call

Uday: w.r.t. to organization .... how many further TD calls

SK: I expect one more
... Let's try to resolve issues
... hope we can freeze document next week
... not sure about API changes
... we will then tag and publish a freezed CP document