Meeting minutes
Policy to update the spec from now on
Kaz: note we should be clear about our policy on how to update the TD 1.1 spec at this stage because we're already CR transition phase
Sebastian: right
… only editorial fixes to be applied
McCool: right
Sebastian: so we should be clear about the policy
… on the other hand, there is difficult discussion on Event handling
McCool: right
… also should note that "editorial fixes" don't necessarily informative but sometimes could be normative, e.g., due to the TAG review feedback
McCool: (although we should prioritize "bug fixes" in normative content during the CR candidate review period, since after CR transition we can't touch any of that)
Sebastian: how to clarify the policy?
Kaz: probably we should put something on the top page of the wot-thing-description repo
Sebastian: ok
… can generate some initial proposal
Kaz: tx
… and ideally, the same policy should be applied to all the normative specs
… so would suggest we make resolution during the main call about applying that policy to the other specs as well
Minutes
Sebastian: (goes through the minutes)
approved
Sebastian: please just note that the IANA registration procedure is still ongoing
PRs
PR 1564
PR 1564 - explain contentType usage
Sebastian: additional diagram on the possible combination of the contentType
… note it's informative
Kaz: how many parameters can be combined in this case?
Ege: 11 parameters, I think
Kaz: for example, we can use RDB to manage data in general
… and simple data tables can be multiplied using the SQL's join command
… so I was wondering about how many tables including how many parameters to be multiplied in which way in this case
… we should clearly define what kind of parameter to be combined/multiplied with each other
… and describe that as an algorithm for this feature
Sebastian: this is informative improvement, so actually doing nothing additional is also an option
Kaz: that's also fine :)
PR 1649
PR 1649 - Allow flexible chartacter for self-contained TDs from TMs
Sebastian: long discussion here
Sebastian: concern on potential name collision
… and how to overcome that?
… several possible options
opt 1. no self-contained TD can be generated: only hierarchy based TDs
can be generated (example)
opt 2. if you own the TMs: change all the affordances names that
potential causes collisions in a TM composition
opt 3. rename affordances in the TD instance that would causes name
collusions, e.g., by the instanceName prefix approach
opt 4. per default, all sub-TM affordances are renamed in the TD
instance (e.g., as shown in this example).
Kaz: actually, I still would like to suggest we split TM from TD, and generate a separate document for TM. and then continue the discussion on how to generate TD from TD separately.
McCool: agree it would be clearer to split TM from TD
… but at this stage, we should think about how to resolve the issues here
Sebastian: yeah
… not making normative assertions, e.g., MUST, SHOULD, is an option
… since we could have different possible solutions depending the cases
… so would remove the assertion, and keep it simpler
McCool: do we have strategy on the processing?
Sebastian: several possible approaches are defined within the TD spec
McCool: ok
Sebastian: any other comments?
Daniel: would agree with Sebastian
Kaz: yeah
… and for TD 2.0, we should think about the detailed algorithm for TM
… maybe we might want to consider Cristiano's mentioning approach as well at that time
… that's basically inline with what I mentioned last week
(PR 1649 itself ha been merged)
PR 1650
McCool: seems it's a bit redundant
Sebastian: however, there is a "should"
McCool: that "should" should remain non-normative
… need some more editorial clean-up
Sebastian: ok
McCool: in general, adding a new assertion from now would cause extra work
… that said, we have URL and JSON Pointer already
(PR 1650 has been merged)
PR 1652
PR 1652 - any type explaination
(merged)
PR 1666
Sebastian: editorial fix
Daniel: the first link says "RFC 6901 section 3" but the second link just says "section 6"
Kaz: we can simply say "section 3 and section 6 from RFC 6901"
McCool: that's fine
… note we need to remove an extra "</a>" right before "section 6"
Sebastian: ok
(merged)
PR 1558
PR 1558 - addresses CR 1.1 candidate review from Oracle
Daniel: new assertions to be added?
Sebastian: a "MUST" to be added here
McCool: it means we don't allow other cases since it says "MUST be case sensitive"
Ege: yeah, Lagally would like to add that assertion
McCool: the question is how to test that new assertion
Sebastian: should we remove it again?
McCool: can keep it
… the sentence itself is fine if it's informative
Kaz: I'm OK with either way but we should be aware of our own policy of case sensitivity within the TD spec as a whole
McCool: it depends on JSON-LD as well
… that said, the send sentence starting with "Please note..." should be "In particular"
(the conclusion is making the 2nd sentence non-normative)
Kaz: ok
… and we need to get back to Lagally as well. right?
Sebastian: right
… (visits the table after the text, specifically about "security")
… McCool, what do you think?
McCool: personally would keep the original text highlighted by red (within the diff)
… that's fine
… every table row is already included in assertions
Ege: should I revert it then?
table within section 5.3.1.1 Thing - see the row of "security" vocabulary term
Sebastian: don't want to change the text from now since it was included in TD 1.0 already
McCool: think the original text is fine
Kaz: ok with either way
… but please consider the impact for the implementers
… and which would be easier for developers to understand the meaning and implement the WoT Thing Description
McCool: don't think we need further clarification here
Kaz: ok
McCool: can create another issue on what "satisfy" here means
new issue 1667 - Define what "satisfying" a securityDefinition means
Sebastian: tx
… (visit "5.3.2.6 ObjectSchema" next)
… (then "5.3.3.1 SecurityScheme")
McCool: think the original text was clearer
… having the sentence as one assertion is fine
Sebastian: in that case, should revert the change?
McCool: yes
<McCool> https://
McCool: just created an issue on "out of band" wording
Sebastian: btw, please remove the "ISSUE 1" at the beginning of "7.1.3 Example III: Geolocation Annotations"
7.1.3 Example III: Geolocation Annotations
Sebastian: (visits "11. Privacy Considerations")
Kaz: btw, this PR is kind of too big
… so would suggest we create smaller separate PRs for big improvements
Sebastian: (goes back to section 5.3)
Sebastian: the 2nd sentence now says "Please note that all vocabulary terms and values are case sensitive."
McCool: should say "In particular" following the first paragraph
Sebastian: ok. let's add further edit
… (goes through the other changes again)
… OK to merge the PR after adding the fixes we identified today
(merged)
Kaz: please check with Lagally and make sure the edit by PR 1558 is OK by him too.
Next call
Sebastian: no TD call next week
Sebastian: while I'm on vacation, Ege will moderate the call on Binding topics
[adjourned]