<kaz> scribenick: dape

decisions about new TD version

SK: Next week will be the last TD call
... next week I would like to discuss PlugFest topics
... should finalize TD version
... updated CP document according to change requests
... got additional comments, see https://github.com/w3c/wot/issues/287
... issue is about renaming... re-structering
... MK proposed changes
... we should manage today to make a decision and get ready for next PlugFest
... MK proposed to use Web vocabulary
... e.g., link vs endpoint
... e.g., uri vs. href
... e.g., mediaType vs type

MK: split up issue into 2

SK: issue #289

<inserted> Issue-289

MK: Instead of uri we should call it href
... endpoint is usually socket address..

<inserted> Matthias' proposal

MK: propose to use link and href
... this is mainly about name changes
... also propose simplifying overall structure
... under interaction you have links
... should we allow multiple hrefs?
... looked at web linking RFC.. just one mediatype is supported
... propose ONE mediaType as shown in example
... one more tweak... in metadata there is key "base"
... essentially base uri
... instead of allowing array it should be at most ONE base uri
... alternate protocols may use absolute uri

SK: changes are as follows
... instead of endpoint we use links

<kaz> (much noise on WebEx and people had to rejoin...)

SK: question to group. What do people think
... should simplify processing.. no arithmetic for detecting right uri et cetera

DP: +1

MK: +1

TK: think is good

Kaz: +1

Uday: fine by me

YC: +1

DP: what about type vs mediaType?

MK: HTML uses type
... conflict in JSON schema
... however, should be fine
... once we have everything together we might consider special naming
... OR scoping should resolve issue

SK: Agree ... may confuse a bit

DP: see difference in JSON schema vs web-linking type
... JSON schema tools are out there

MK: web linking tools come up also..
... so same same
... TD uses metadata around actual web linking node
... link for "temperature" is the actual link and not the current TD

SK: what if we keep mediaType?

MK: breaks web linking.. which is somewhat broken anyway

DP: Let's try to stick with type and see whether we run into problems... should be resolvable according context

SK: Darko, do you see any issues?

Darko: where is "type" defined?
... propose to define contexts for IANA and JSON schema

SK: prefix should make it clear

DP: propose to look whether prefixes break JSON schema tools

Darko: Not sure about the issue... JSON schema tools have issue already .. type is there twice

DP/MK: context will resolve issue

Darko: agree w.r.t. to processing but not w.r.t. semantics

MK: think we need proper model to resolve those and similar issues
... e.g., valid JSON-LD document

Darko: local "type" without prefix means part of TD ... not of JSON Schema

SK: How can we solve the issue?
... going back to mediaType key OR look into JSON-LD and how we can resolve this issue

MK: It is not proper fixed by just renaming
... scoping/context should apply
... for hot fixing propose to rename it to mediaType
... anyhow.. have to look into how to resolve it

SK: OK, lets rename it back to mediaType

Naka: seems ok also for me

SK: MK had other issue, #290
... rename outputType just to output

<kaz> Issue-290

MK: compared to other examples, outputType, valueType etc it is just a hook
... get rid of obsoletes nodes and simplify to input and output

SK: I do not have a strong opinion
... type is already in JSON schema... et cetera

MK: renaming is less critical...
... can reconsider that anyway... short and simple

DP: Can you show example..

<kaz Example TD for Structured Data

MK: remove "valueType"

SK: not sure anymore why we had "valueType" in the first place
... guess it was based on semantic annotation

MK: propose to put semantic on "type" level

DP: breaks JSON schema tools

MK: not doing it causes issues with semantic annotations in complex types

SK: JSON schema people restarted their work
... should get in touch with them

DP: Propose to get in touch with them
... raise issues

SK: can do that

Darko: would not remove valueType unless issue is resolved

MK: OK. lets put that on hold

SK: Will integrate changes to CP
... freeze CP latest next week
... next week is about PlugFest scenarios

[ adjourned ]