- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 27 Jan 2021 18:44:48 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/01/13-wot-td-minutes.html
also as text below.
Thanks a lot for taking the minutes, Cristiano!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT-WG - TD-TF
13 January 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Jan_13.2C_2021
[3] https://www.w3.org/2021/01/13-wot-td-irc
Attendees
Present
Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan,
Kaz_Ashimura, Michael_Koster, Michael_McCool,
Sebastian_Kaebisch, Taki_Kamiya, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian
Scribe
cris
Contents
1. [4]Preliminaries
2. [5]previous minutes
3. [6]Defer issue to TD 2.0
4. [7]Pull requests
5. [8]issues
Meeting minutes
Preliminaries
Sebastian: happy new year to everybody.
… today we'll focus mainly on the topics from GitHub issues
… anything else to be added to the agenda?
… ok
previous minutes
<kaz> [9]Dec-16 minutes
[9] https://www.w3.org/2020/12/16-wot-td-minutes.html
Sebastian: we had some discussion on IETF ASDF meeting
… in particular how SDF can be transformed to an Thing Model
McCool: I expect to have a SPARQL directory for the next
PlugFest, we can experiment there with SDF
Sebastian: I have also a student who's working on this topic
McCool: about Plugfest please if you have any other topic that
you want to be covered please feel free to ping me.
Sebastian: we postponed TD "produced" field for the next
version. it needs more discussion
Sebastian: another issue was about having multiple methods
names. You have defined a default mapping to transform a single
form with multiple ops
<kaz> [10]Issue 712 - Multiple methodName's
[10] https://github.com/w3c/wot-thing-description/issues/712
McCool: one problem is that it is odd to have one method name
and multiple ops
… we probably need an assertion to avoid this situation.
Daniel: I disagree it is possible to have a PUT method to both
read and write
McCool: how do you distinguish between the operations?
… it is ambiguous
… we may use SHOULD instead of MUST
Sebastian: what about the assertion made in issue comment?
about the transformation?
McCool: I agree with that
Sebastian: next topic was about 617 and we'll probably continue
today
McCool: yes it is relevant for discovery, in particular for
multiple error responses
… I think is a good feature but we have to think about retro
compatibility
Sebastian: minutes approved
Defer issue to TD 2.0
<sebastian> [11]https://github.com/w3c/wot-thing-description/
issues?q=is%3Aissue+is%3Aopen+label%3A%22Defer+to+TD+2.0%22
[11] https://github.com/w3c/wot-thing-description/issues?q=is:issue+is:open+label:"Defer+to+TD+2.0"
McCool: I think there might be a set of issue like the one
about multiple responses that need to be deferred because of
their impact in retro compatibility
Sebastian: the list linked in not complete, please ping me to
add more
Sebastian: I also made a label to tag old issues or issues that
could be closed
McCool: the geolocation issue is still open, please remove the
label
Sebastian: ok I removed the label
McCool: my concern about geolocation is that we need a
definitive structure to do geo based searches in directories
… probably we might need a separate document with best
practices or guidelines for geolocation with WoT
Pull requests
<kaz> [12]PR1027
[12] https://github.com/w3c/wot-thing-description/pull/1027
Sebastian: the first one is from kaz. The main change is the
modification of the spec status
… plus he remove the image width
Kaz: yes it is an obsolete feature.
Sebastian: plus there are some automatically generated files
Sebastian: it seems fine to me. Any other comments?
Kaz: I mentioned during the architecture call as well: we
should have a naming convention for IDs for sections, figures
and examples
McCool: I wouldn't change it now.
<kaz> kaz: in any case, if there are duplicated IDs, I'll fix
them before publication.
Sebastian: ok merged
… then there are two wip PRs
<kaz> [13]PR1025
[13] https://github.com/w3c/wot-thing-description/pull/1025
<kaz> s/wip PRS/wip PRS, PR1025 and PR1024/
Sebastian: daniel found some capitalization errors about the
observeall operation
Sebastian: it might be an error of the render script
Sebastian: then there's a PR about the Thing Model chapter
Sebastian: we have some agreement for introducing a version for
the model. it can be also used in a TD instance
… also we have a small consensus about how to link the model in
TD using the link field.
… I add SDF to TM example
Cristiano: is the version field optional?
Sebastian: yes it is optional
<kaz> [14]PR1021
[14] https://github.com/w3c/wot-thing-description/pull/1021
Sebastian: next PR is about issue 1010
Sebastian: is it from daniel and it introduces the
exclusiveMaxium and exclusiveMinimun terms
… does SDF have this terms?
Koster: no, I don't think so, but let me check
… oh we have it then.
… sometime you need it. Is it not a problem to include it
McCool: certainly consistency with JSONSchema is good
Sebastian: ok then the PR looks good so far.
… ok there's is some conflicts. It is probably related to the
kaz PR merge.
Daniel: since it is a generated image that is in conflict we
could ignore it and merge it anyway. It will be overwritten
Sebastian: ok merged
<kaz> [15]PR964
[15] https://github.com/w3c/wot-thing-description/pull/964
<kaz> [16]PR924
[16] https://github.com/w3c/wot-thing-description/pull/924
Daniel: can we remove the Bump PRs? they are old
… no big deal
Kaz: I think I need to look into the settings
Sebastian: I'll propose to test those and see if the render
script will work correctly.
Sebastian: there's another old PR from mc
McCool: unfortunately this PR was broken by the update of the
render script. I'll work on it
… probably I'll create a new one
<kaz> [17]PR945
[17] https://github.com/w3c/wot-thing-description/pull/945
Sebastian: what about 945?
McCool: it breaks compatibility so it is deferred.
issues
<kaz> [18]Issue 617
[18] https://github.com/w3c/wot-thing-description/issues/617
Sebastian: the first one is multiple responses in a form
… one problem there is again backward compatibility.
McCool: one workaround is to add a new term (i.e., responses)
Sebastian: yeah it is like title and titles
Ege: I like responses, but I am afraid for typos if we have
response togheter with responses. we could remove response in
future versions
McCool: is response mandatory
Ege: yes
McCool: it might still not 100% retrocompatible
… old system wouldn't understand
… responses
Sebastian: I like the proposal. but can we say that respose be
a single value or an array
McCool: is not backward compatible
Sebastian: we might do an exception here
… I also like responses tough
Daniel: I tend to agree to keep response as it is and add a new
term for other responses
<McCool> to clarify, I was propose adding an
"additionalResponses" field for "other" responses
Cristiano: what about dataschema?
Sebastian: it reminds me the discussion we had with
hyperschema.
… we talked about other fields to describe multiple payloads
types
McCool: JSONschema allows multiple choices.
Koster: but we cannot map to a particular response
… in SDF we'll use a json pointer to indicate the data schema
McCool: how do we distinguish different responses? with http we
have different codes. we could use dataschema even to define
different responses
… the challenge is how to use headers to distinguish between
responses
Koster: json pointers are useful when referring other pieces of
information inside a json document.
McCool: it could be really simple if relative to the schema
Koster: let's look at some example and try it
McCool: because we have a concrete use-case in the discovery
let's start from there
Sebastian: so to conclude: one step is decide if to include a
new terms form multiple responses. last how to point
dataschemas from responses
… json pointers is on the table as one possibile solution for
the second point.
<mjk_> We prefer "anyOf" rather than "oneOf" for reasons
McCool: dealing with errors is a gap that we have in TD, we
should work to fix this missing feature.
<mjk> [19]https://github.com/ietf-wg-asdf/SDF/pull/8
[19] https://github.com/ietf-wg-asdf/SDF/pull/8
<mjk> discussion of use of "anyOf"
Sebastian: mc can you take responsibility for this issue?
McCool: yes I'll bring this up in the Discovery task force and
then Farshid or I will provide a PR
<kaz> [20]Issue 923
[20] https://github.com/w3c/wot-thing-description/issues/923
Sebastian: next issue is about a security scheme for Philips
light bulbs.
McCool: yes we reviewed in security task fource. basically keys
are embedded in URIs and we cannot describe it
McCool: I proposed a new scheme, much like the one that ege is
suggesting in the issue tracker
… it is still a open problem but we have to introduce this new
mechanism to handle URI templates
… I don't have a PR yet. I'll try to create one before Monday
… if anyone has more examples of URI embedded security
parameter please comment in the issue
… I'll also improve the API key documentation
Ege: why don't use this pattern inside the API key?
McCool: yes we'll do
… we'll have a new "in" value (i.e., URItemplate)
Sebastian: maybe ege you could join the security call and
discuss about the new proposal
<kaz> [21]Issue 307
[21] https://github.com/w3c/wot-thing-description/issues/307
Sebastian: next issue 307
… it is an old issue and it's about introducing $ref pointers
inside the TD
… the major usecase is to minimize redundancy
… also you can change one definition in one place
… Legally mentioned about the recursive problems
Ege: jsonschema avoid it by disallow recursive refs
… also we have to pay attention about how to include
definitions or other schemas
Koster: we had this in SDF, but we dropped it. It is too narrow
because $ref should point always to a schema
… like ege mentioned it is not clear if you can put a URI
there. Therefore we coined a new pointer
… we have to be careful to use $ref for this limitations. In TD
it is best to introduce a new term
Sebastian: should we also avoid the $ref to point to other json
objects?
Koster: because $ref means precisely use the schema at this
location.
<kaz> [22]sdfRef
[22] https://ietf-wg-asdf.github.io/SDF/sdf.html#sdfref
McCool: I think this is a 2.0 feature.
Koster: true
Sebastian: agree
McCool: we could pre process a TD with this new feature and
convert it back
Daniel: what about JSON-LD? is this new feature working with
it?
… victor had some points about the issue
Koster: probably in json-ld you'll use a fragment identifier
McCool: I don't know, it looks different in json-ld
Koster: Is an URI with a fragment in RDF.
Ege: one point of pre processing. we could introduce this
feature in TD model instead of TDs
McCool: right and in 2.0 we could introduce it in TDs
McCool: is there a frame for generating a TD back from RDF?
Koster: great idea to use in TM
<kaz> [23]issue 1015
[23] https://github.com/w3c/wot-thing-description/issues/1015
Sebastian: about framing, McCool, could you provide a PR?
McCool: I think there's an issue somewhere
<McCool> (have to drop, sorry)
Kaz: we might want to talk with DID group about the framing
issue
… JSON-LD group suggested this also.
<kaz> [adjourned]
Minutes manually created (not a transcript), formatted by
[24]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[24] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 27 January 2021 09:44:54 UTC