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://
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://
Sebastian: ok, then will merge - merged
https://
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]