W3C

– DRAFT –
WoT-WG - TD-TF

03 August 2022

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Farshid_Tavakolizadeh, Kaz_Ashimura, Michael_Koster, Michael_Lagally, Michael_McCool, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Sebastian
Scribe
cris, kaz, McCool

Meeting minutes

Review Comments

Sebastian: ML has to leave early, so suggest we review these review comments first
… Ege also split them into multiple issues
… there is also a PR where I tried to address some of these comments
… I think many of them are addressed, but some still open
… there is a list of issues, search for [OracleReview]

Lagally: I added comments to many of them, best to skim list from top to bottom

issue #1619

<kaz> Issue 1619 - [OracleReview] 11.3.1 Versioning

Sebastian: TM had versioning
… is special section, with an example

Lagally: it looks like first line has been changed to an assertion, so resolved
… however, says SHOULD, is not mandatory

Sebastian: however, is also optional in TD, up to the application

Lagally: ok, not as strong a guarantee

Sebastian: think this makes sense to include in a profile

Lagally: ok, let's close this one

issue #1618

<kaz> Issue 1618 - [OracleReview] 11. Thing Model

Lagally: this is about a section marked as WIP

Sebastian: covered by a PR already available
… PR #1558
… which deletes the note

<kaz> PR 1558 - WIP: addresses CR 1.1 candidate review from Oracle

#1617

<kaz> Issue 1617 - [OracleReview] 6.3.4 securityDefinitions and security

McCool: I think the security TF needs to review this one; don't want redundant assertions
… however, should look also at other things, like whether Maps can be empty

issue 1616

<kaz> Issue 1616 - [OracleReview] 5.3.4.2 Form

Sebastian: about Form

Lagally: ExpectedResponse and AdditionalExpectedResponse

McCool: I think it was a technical problem with compatibility

Sebastian: see also the cited PR, tried to address this

issue #1615

<kaz> Issue 1615 - [OracleReview] 5.3.1.6 VersionInfo

Sebastian: had looked at this in the past as well; defacto semantic versioning, but there was some pushback
… but some companies have their own strategy, which is why is optional

Lagally: issue is that it is not an RFC2119 assertion, just informative

McCool: I am ok with making this an assertion; should not impact testing much

Sebastian: ok with me also
… I will do a PR

#1614

<kaz> Issue 1614 - [OracleReview] OAuth2SecurityScheme

McCool: agree this sentence should be moved out of the table and made an assertion.
… we can look at in the next security call

issue #1613

<kaz> Issue 1613 - [OracleReview] 5.3.3.1 SecurityScheme

Lagally: some things here not related to security

McCool: think we should remove some of these and break it down into different issues

Sebastian: think it makes sense to add cancelallactions

McCool: but not for an emergency stop

McCool: we also need some implementations for some related new ops, e.g. "cancelaction"

Sebastian: plenty of such features, do we need it?

Lagally: you can work around this specific op

McCool: I brought it up since I thought it was in profile

Lagally: ok, let me think about it and check profile
… profile only uses queryallactions

Sebastian: so ok to postpone to next version

Lagally: have to go, unfortunately

Sebastian: would be good to discuss rest using the issue tracker

Lagally: ok. have to go, take care

PR #1629

Sebastian: simple, just updating change log to be consistent with now-published WD

McCool: let's do it, easy

Sebastian: merging

Kaz: just to make sure, does this PR include the change for OAuth reference?

Daniel: that part was handled by another PR by McCool.

PR #1639

<kaz> PR 1639 - Adjust policy-like security assertions

McCool: this is to address some TAG feedback

dape: seems to be a problem with "any type" in the rendered version

McCool: but if only in the rendered version will be fixed when we re-render

Sebastian: this is a SHACL issue; render script issue

McCool: so three assertions removed, one merged with another

<kaz> (trouble with being merged due to recent rechartering, so McCool creates another PR.)

PR 1642

<kaz> PR 1642 - SHACLE Type fixes

Sebastian: this PR should solve the render problem
… it was cause by an issue with the SHACL definition
… an old PR used node kind
… which is more powerful
… the PR re-introduce the dataType
… it should fix the problem at least
… my proposal is to merge this
… and then fix it later

Cristiano: I would go ahead with the PR
… but we should discuss more about the fixes

Sebastian: I agree

Kaz: have you talked with Elodie?

Sebastian: she is not available now

Kaz: why don't we ask the JSON-LD guys for help?

Sebastian: it is a complex issue

Cristiano: I can volunteer digging deeper on the issue

Sebastian: thank you

mc: previous PR issue should be resolved now

PR #1639

<kaz> PR 1639 - Adjust policy-like security assertions

McCool: removed index.html

Sebastian: ok, let's merge

PR #1645

<kaz> PR 1645 - fix type of additionalResponses and ComboSec oneOf and allOf

Cristiano: issue was needed to set proper container in context, then rendering will work correctly
... also manually removed changes due to the other problem we just discussed
… in index.html

Sebastian: (looks at rendering, checks) - looks correct, suggest we merge
… any objections to merge? hearing none - merges

Issue #1594

<kaz> Issue 1594 - Using tm:required for non-affordance members

Sebastian: some context, TM has "required" feature
… taken from JSON Schema paradigm

Sebastian: which says there are some key-value pairs that should always be in target
… but from experience from implementations, it turns out to be annoying
… expectation is typically that everything is required, since that is generally the point of TMs
… but there might be some exceptions where there is a non-mandatory feature
… so more useful to go the other way around, and use "tm:optional" rather than "tm:required"
… there was all the question whether we need it at all
… so we could also solve this another way
… e.g. by referring to variant thing models
… but this could get complicated

<FarshidT> Sorry guys, I have to drop and join another call. I've commented on the issue on the discovery side: https://github.com/w3c/wot-discovery/issues/384

Sebastian: at any rate, this PR introduces tm:optional in place of tm:required

Sebastian: note also this would cause this assertion to be at risk, since we don't have implementations yet.
… but should not be difficult

<kaz> related PR 1640 - init tm:optional

McCool: I am ok with it as a stand-alone concept, the only issue is deviation from JSON Schema

Sebastian: true, but this is about interactions, not about data schema
… is more like object-oriented modelling/programming instead of data schema modelling

<kaz> preview - 9.3.4 tm:optional

McCool: is there any clean way to have both?

Sebastian: we were thinking about that, but there were argument against it

Cristiano: basically makes everything more complex.

McCool: was going to suggest making required the default, but then if it appears making other things optional by implication

Kaz: I think we need big reasons for changes at this stage

Sebastian: it is however quite annoying, you have to list all the affordances all the time

Kaz: technically I can understand, but need to explain intention of this big change

Sebastian: yes, needs to be justified in change log clearly

Kaz: just saying it is annoying is not enough

Koster: my experience is not clear how these would be processed in TD
… really don't process optionality when you are defining something
… in oneDM and Matter, have found need to describe features that are have more than one "node"
… things that always go together, "feature sets"
… for example "cancellable actions", or "logging"
… each have extra properties and events
… don't have design to propose

McCool: does SDF use required or optional?

Koster: required, but have base functionality
… but we are looking at some improvements in composibility
… lower-level syntax do use JSON Schema, properties needed in an object
… TM is for composing, TD is after you have selected optionality
… is tm:required JSON pointer?

Sebastian: yes

Koster: ok, so that is not exactly aligned with JSON Schema
… it won't *break* JSON Schema

Sebastian: that's right; even use "tm:" prefix to distinguish

Koster: so a difference in polarity

Sebastian: you said TM is just defining opportunties for what TD should look like
… but it's also a template
… as a manufacturer, you are defining what is provided by the device
… so the assumption is that if you are spending time in TM modelling, is because you expect them to be in the TD

Cristiano: original use case for TM
… differ from JSON Schema, in that we have use case in mind
… not validation, is description
… are answering question whether we can produce a TD, not whether it is valid

Koster: in SDF found it is useful to express both optionality and mandatoriness

Sebastian: just the question of which is more practical
… and our experience is that "optional" would be more practical

Sebastian: assumption is that things in TM will generally be in a TD

Koster: only exception I have seen is if you have a big enum, but don't see that as a gating item
… in generative case we more want to say what the core items are, then the options

McCool: to summarize, two downsides are JSON schema and lateness
… discussion seems to be that the JSON Schema issue is not as important as the modelling ease of use
… also the people proposing this are mostly people who have already provided examples
… we would also need to update the discovery spec, which uses tm:required currently
… on the other hand, fixing the directory TMs alone would satisfy the test requirements...

Kaz: would agree given it would be useful and productive for implementers if we provide this change, but we still need to explain the need and expected usefulness within the spec./

https://github.com/w3c/wot-discovery/issues/388

Sebastian: ok, then will merge - merged

https://github.com/w3c/wot-discovery/issues/384

Kaz: note that Farshid also created Issue 384 around this topic

Publication

<kaz> TD WD4

Sebastian: kaz cleaned up and published the WD
… this is the basis of the version used for CR, but there are some pending changes
… thing it is fairly stable and much improved

McCool: think we should aim for a resolution at TPAC for CR transition
… still need some work, then call for a resolution, have a two-week internal review, etc.

Sebastian: should at least try to address Oracle's feedback

McCool: we can try to address at least the security things on Monday and generate PRs for thoes
… in general, these are all editorial changes, even if they technically might create some new assertions

Sebastian: think we need at least one more week
… resolve these, then start review phase

Kaz: seb, will you be available next Wed?

Sebastian: am on a workshop, will try to escape for a few minutes

McCool: so we should have someone else chair, you can join in the last 15m to have resolution

McCool: also need to explicitly list atrisk items and sections, can do that after we lock down the CR candidate

Sebastian: in other news, IANA request is still under discussion

minutes

<kaz> July-20

Sebastian: any objections to publish?
… hearing none, let's publish

<kaz> [adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 147 (Thu Jun 24 22:21:39 2021 UTC).