13 January 2021


Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Kaz_Ashimura, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Taki_Kamiya, Tomoaki_Mizushima

Meeting minutes


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> Dec-16 minutes

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> Issue 712 - Multiple methodName's

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> https://github.com/w3c/wot-thing-description/issues?q=is%3Aissue+is%3Aopen+label%3A%22Defer+to+TD+2.0%22

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> PR1027

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> PR1025

<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> PR1021

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> PR964

<kaz> PR924

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> PR945

Sebastian: what about 945?

McCool: it breaks compatibility so it is deferred.


<kaz> Issue 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> 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> Issue 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> Issue 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> 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> issue 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 scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).