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> 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://
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.
issues
<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://
<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]