Meeting minutes
Mintues
approved
CR Transition
Sebastian: wait until the results of the next Testfest in July (July 25-29)
… CR resolution on August 3
PRs
PR 1549
PR 1549 - Add husky pre-commit for rendering
Sebastian: Ege is not here
… also not an urgent PR
… so let's defer to the next call
<cris_> +1
McCool: sure
PR 1552
PR 1552 - Add informative text and an example for relative tm:ref
Sebastian: "tm:ref": "#/properties/genericTemperature"
Jan: should be OK
ca: derivation is not described there
Jan: could be clarified
ca: other than that, the PR is OK
… we can create another issue
9.4 Derivation of Thing Description Instances
Sebastian: Cristiano, can you create an issue about that?
ca: will do
Sebastian: some trouble with the Repo Manager
Kaz: would suggest you check the account setting to make sure
Sebastian: but can merge it :)
(merged)
PR 1555
PR 1555 - add missing rfc-2119 keyowrds
Sebastian: small edit fixing the RFC 2119 keywords
(merged)
related Issue 1523 - Missing RFC-2119 Keywords in Assertions
(closed)
PR 1558
PR 1558 - WIP: addresses CR 1.1 candidate review from Oracle
(keep it open)
Issues
Issue 1554
Issue 1554 - Further Improve Discussion of Secure Transport in Security Schemes
McCool: some schemes are less secure that TLS
… right now the description is binary
… but should be relative
… right now TLS is required
… other than "nosec"
… Security TF will discuss it
… likely a PR for improvement
Sebastian: ok
Issue 1556
Issue 1556 - Flexible character for instanceName in Thing Model definition
Sebastian: Example 59 shows examples of different Thing Models
Sebastian: don't think we should have the assertion after Example 59 saying:
If it is desired to provide information that a Thing Model consists of one or more (sub-)Thing Models, the links entries MUST use the "rel":"tm:submodel" that targets to the (sub-) Thing Models. Optionally an instanceName MAY be provided to associate an individual name to the composed (sub-) Thing Model.
Kaz: we should have some clear policy about the notation
… and that should be decided based on implementers' feedback
Sebastian: already had some feedback
… think TD should be open about the notation
Kaz: ok
… probably we should have some more discussion on WoT implementers and other related spec implementers
… we can't force any specific coding style at the moment, though
… maybe we can generate a separate Note on the best practices for TD coding
Sebastian: yeah
Issue 1530
Issue 1530 - Overlapping fields between DataSchema, InteractionAffordance and few concrete elements
Sebastian: @type, title, titles, description, descriptions are commonly used for InteractionAffordance and DataSchema
… Ege described the history
Sebastian: when we work on the next version, we could consider more precise definition
… but can't do anything for 1.1
Kaz: from my viewpoint, the important point is clarity of definition
… we could specify namespaces for each vocabulary strictly if we need
… don't think we need to change the vocabulary at this stage
ca: agree with the need for clarity
Issue 1557
Issue 1557 - Missing keywords for "in" property in "APIKeySecurityScheme"
Sebastian: missing definition
Jan: 2 missing values there
ca: probably we didn't synchronize them
Jan: Fady also mentioned "uri" and "auto"
McCool: "auto" belongs to everywhere
… let's make a PR, and I can review it during the Security TF call
… adding "uri" would make sense, though "auto" should not
… the spec and the schema should be consistent
TD draft - 5.3.3.8 BearerSecurityScheme
McCool: let's fix the schema to make it consistent with the spec
… let's once add "auto" as well
Kaz: so Ege is encouraged to create a PR including "uri" and "auto" for the schema, and the Security TF will review it. right?
McCool: the schema should be consistent with the spec
… so we'll review it
[adjourned]