14:05:26 RRSAgent has joined #wot-td 14:05:26 logging to https://www.w3.org/2022/08/17-wot-td-irc 14:05:35 meeting: WoT-WG - TD-TF 14:05:56 present+ Kaz_Ashimura, Daniel_Peintner, Ege_Korkan, Michael_McCool, Sebastian_Kaebisch 14:06:02 chair: Sebastian 14:06:52 Mizushima has joined #wot-td 14:07:08 sebastian_ has joined #wot-td 14:07:38 regrets+ Michael_Koster 14:09:30 scribenick: Kaz 14:09:55 q+ 14:10:08 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#August_17.2C_2022 14:12:59 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 14:13:03 sk: right 14:13:22 ... only editorial fixes to be applied 14:13:25 mm: right 14:13:40 sk: so we should be clear about the policy 14:13:45 q+ 14:13:50 ack k 14:14:06 ... on the other hand, there is difficult discussion on Event handling 14:14:13 mm: right 14:15:43 ... also should note that "editorial fixes" don't necessarily informative but sometimes could be normative, e.g., due to the TAG review feedback 14:15:51 mm: (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) 14:16:05 sk: how to clarify the policy? 14:16:27 kaz: probably we should put something on the top page of the wot-thing-description repo 14:16:56 sk: ok 14:17:18 ... can generate some initial proposal 14:17:22 kaz: tx 14:17:36 ... and ideally, the same policy should be applied to all the normative specs 14:18:18 ... so would suggest we make resolution during the main call about applying that policy to the other specs as well 14:18:45 i/note we should/topic: Policy to update the spec from now on/ 14:18:50 topic: Minutes 14:19:06 -> https://www.w3.org/2022/08/10-wot-td-minutes.html Aug-10 14:19:27 sk: (goes through the minutes) 14:19:40 rrsagent, make log public 14:19:48 rrsagent, draft minutes 14:19:48 I have made the request to generate https://www.w3.org/2022/08/17-wot-td-minutes.html kaz 14:22:00 JKRhb has joined #wot-td 14:24:54 present+ Tomoaki_Mizushima 14:25:37 approved 14:25:49 sk: please just note that the IANA registration procedure is still ongoing 14:26:12 topic: PRs 14:26:38 i|PRs|-> https://github.com/w3c/wot-thing-description/issues/931 Issue 931 - IANA registration for Thing Model content type 14:26:51 subtopic: PR 1564 14:27:20 -> https://github.com/w3c/wot-thing-description/pull/1564 PR 1564 - explain contentType usage 14:27:43 sk: additional diagram on the possible combination of the contentType 14:27:51 ... note it's informative 14:28:58 q+ 14:29:15 ack m 14:29:18 ack m 14:29:25 ack k 14:30:15 kaz: how many parameters can be combined in this case? 14:30:45 ek: 11 parameters, I think 14:32:39 kaz: for example, we can use RDB to manage data in general 14:33:00 ... and simple data tables can be multiplied using the SQL's join command 14:33:30 ... so I was wondering about how many tables including how many parameters to be multiplied in which way in this case 14:36:05 ... we should clearly define what kind of parameter to be combined/multiplied with each other 14:36:28 ... and describe that as an algorithm for this feature 14:37:55 sk: this is informative improvement, so actually doing nothing additional is also an option 14:38:01 kaz: that's also fine :) 14:38:26 subtopic: PR 1649 14:38:48 -> https://github.com/w3c/wot-thing-description/pull/1649 PR 1649 - Allow flexible chartacter for self-contained TDs from TMs 14:38:59 sk: long discussion here 14:40:25 -> https://github.com/w3c/wot-thing-description/pull/1649#issuecomment-1216825661 Sebastian's latest comments 14:40:34 sk: concern on potential name collision 14:40:52 ... and how to overcome that? 14:43:06 ... several possible options 14:43:25 [[ 14:43:26 no self-contained TD can be generated: only hierarchy based TDs can be generated (example) 14:43:26 if you own the TMs: change all the affordances names that potential causes collisions in a TM composition 14:43:26 rename affordances in the TD instance that would causes name collusions, e.g., by the instanceName prefix approach 14:43:27 per default, all sub-TM affordances are renamed in the TD instance (e.g., as shown in this example). 14:43:29 ]] 14:43:36 s/no/opt 1. no/ 14:43:52 s/if you own/opt 2. if you own/ 14:44:03 s/rename a/opt 3. rename a/ 14:44:12 s/per def/opt 4. per def/ 14:44:15 rrsagent, draft minutes 14:44:15 I have made the request to generate https://www.w3.org/2022/08/17-wot-td-minutes.html kaz 14:45:53 q+ 14:46:35 q+ 14:47:04 ack k 14:47:24 kaz: actually, would like to suggest... 14:47:41 mm: agree it would be clearer to split TM from TD 14:47:56 ... but at this stage, we should think about how to resolve the issues here 14:48:06 sk: yeah 14:48:36 ... not making normative assertions, e.g., MUST, SHOULD, is an option 14:49:05 ... since we could have different possible solutions depending the cases 14:49:12 ack m 14:49:28 ... so would remove the assertion, and keep it simpler 14:50:24 s/suggest.../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./ 14:50:43 mm: do we have strategy on the processing? 14:51:02 sk: several possible approaches are defined within the TD spec 14:51:50 -> https://w3c.github.io/wot-thing-description/#thing-model-composition TD ED - 9.3.3 Composition 14:52:14 mm: ok 14:52:20 sk: any other comments? 14:52:22 (none) 14:52:43 s/(none)/dp: would agree with Sebastian/ 14:52:49 q+ 14:53:18 ack k 14:53:20 kaz: yeah 14:54:25 ... and for TD 2.0, we should think about the detailed algorithm for TM 14:54:48 ... maybe we might want to consider Cristiano's mentioning approach as well at that time 14:54:58 ... that's basically inline with what I mentioned last week 14:56:23 (PR 1649 itself ha been merged) 14:56:45 subtopic: PR 1650 14:57:08 -> https://github.com/w3c/wot-thing-description/pull/1650 PR 1650 - update references for contentEncoding and contentMediaType + extand assertation with another sentance 14:58:50 mm: seems it's a bit redundant 14:59:09 sk: however, there is a "should" 14:59:26 mm: that "should" should remain non-normative 14:59:39 ... need some more editorial clean-up 14:59:46 sk: ok 15:00:12 mm: in general, adding a new assertion from now would cause extra work 15:00:31 ... that said, we have URL and JSON Pointer already 15:01:08 s/would like/I still would like/ 15:05:07 (PR 1650 has been merged) 15:06:34 subtopic: PR 1652 15:06:51 -> https://github.com/w3c/wot-thing-description/pull/1652 PR 1652 - any type explaination 15:06:53 (merged) 15:06:59 subtopic: PR 1666 15:07:23 -> https://github.com/w3c/wot-thing-description/pull/1666 PR 1666 - update link in IANA 15:07:26 sk: editorial fix 15:08:02 q+ 15:08:29 ack d 15:09:28 dp: the first link says "RFC 6901 section 3" but the second link just says "section 6" 15:09:31 q+ 15:09:59 ack dape_ 15:10:04 ack k 15:11:07 kaz: we can simply say "section 3 and section 6 from RFC 6901" 15:11:11 mm: that's fine 15:11:28 ... note we need to remove an extra "" right before "section 6" 15:11:30 sk: ok 15:13:00 (merged) 15:13:14 subtopic: PR 1558 15:13:36 -> https://github.com/w3c/wot-thing-description/pull/1558 PR 1558 - addresses CR 1.1 candidate review from Oracle 15:14:02 q+ 15:14:12 q+ 15:14:13 ack d 15:14:22 dp: new assertions to be added? 15:14:36 sk: a "MUST" to be added here 15:14:58 ack dape_ 15:15:09 mm: it means we don't allow other cases since it says "MUST be case sensitive" 15:15:41 ek: yeah, Lagally would like to add that assertion 15:15:59 mm: the question is how to test that new assertion 15:16:28 sk: should we remove it again? 15:16:34 mm: can keep it 15:17:29 ... the sentence itself is fine if it's informative 15:18:21 q? 15:19:33 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 15:19:44 mm: it depends on JSON-LD as well 15:20:27 ... that said, the send sentence starting with "Please note..." should be "In particular" 15:21:19 (the conclusion is making the 2nd sentence non-normative) 15:21:29 kaz: ok 15:21:52 ... and we need to get back to Lagally as well. right? 15:22:14 sk: right 15:22:52 ... (visits the table after the text, specifically about "security") 15:23:01 ... McCool, what do you think? 15:23:48 mm: personally would keep the original text highlighted by red (within the diff) 15:23:57 ... that's fine 15:24:24 ... every table row is already included in assertions 15:24:32 ek: should I revert it then? 15:25:17 -> https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/1558/103f786...d5b9b2b.html#thing table within section 5.3.1.1 Thing 15:25:55 s/Thing/Thing - see the row of "security" vocabulary term 15:26:07 rrsagent, draft minutes 15:26:07 I have made the request to generate https://www.w3.org/2022/08/17-wot-td-minutes.html kaz 15:27:33 sk: don't want to change the text from now since it was included in TD 1.0 already 15:27:41 q+ 15:28:26 mm: think the original text is fine 15:29:36 kaz: ok with either way 15:29:49 ... but please consider the impact for the implementers 15:30:11 ... and which would be easier for developers to understand the meaning and implement the WoT Thing Description 15:30:31 mm: don't think we need further clarification here 15:30:34 kaz: ok 15:31:54 mm: can create another issue on what "satisfy" here means 15:32:15 sk: tx 15:32:29 ... (visit "5.3.2.6 ObjectSchema" next) 15:33:58 ... (then "5.3.3.1 SecurityScheme") 15:34:17 -> https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/1558/103f786...d5b9b2b.html#securityscheme 5.3.3.1 SecurityScheme 15:34:28 mm: think the original text was clearer 15:36:06 ... having the sentence as one assertion is fine 15:36:22 sk: in that case, should revert the change? 15:36:25 mm: yes 15:37:14 https://github.com/w3c/wot-thing-description/issues/1667 15:38:08 s|https://github.com/w3c/wot-thing-description/issues/1667|| 15:38:26 i|sk: tx|-> https://github.com/w3c/wot-thing-description/issues/1667 new issue 1667 - Define what "satisfying" a securityDefinition means 15:38:36 https://github.com/w3c/wot-thing-description/issues/1669 - out of band wording tweak 15:39:12 sk: btw, please remove the "ISSUE 1" at the beginning of "7.1.3 Example III: Geolocation Annotations" 15:39:30 -> https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/1558/103f786...d5b9b2b.html#semantic-annotations-example-geoloc 7.1.3 Example III: Geolocation Annotations 15:40:07 i/btw/mm: just created an issue on "out of band" wording 15:40:42 sk: (visits "11. Privacy Considerations") 15:40:47 q+ 15:41:42 -> https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/1558/103f786...d5b9b2b.html#sec-privacy-consideration 11. Privacy Considerations 15:42:33 kaz: btw, this PR is kind of too big 15:42:50 ... so would suggest we create smaller separate PRs for big improvements 15:44:09 sk: (goes back to section 5.3) 15:44:37 -> https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/1558/103f786...d5b9b2b.html#class-definitions 5.3 Class Definitions 15:45:11 sk: the 2nd sentence now says "Please note that all vocabulary terms and values are case sensitive." 15:45:25 mm: should say "In particular" following the first paragraph 15:45:38 sk: ok. let's add further edit 15:46:56 ... (goes through the other changes again) 15:47:18 ... OK to merge the PR after adding the fixes we identified today 15:49:25 -> https://github.com/w3c/wot-thing-description/pull/1558/files Changes in the end 15:50:21 (merged) 15:50:29 q? 15:50:46 @@@ 15:50:53 topic: Next call 15:50:59 sk: no TD call next week 15:51:26 q- 15:51:27 q+ 15:53:18 sk: while I'm on vacation, Ege will moderate the call on Binding topics 15:53:27 [adjourned] 15:53:32 rrsagent, draft minutes 15:53:32 I have made the request to generate https://www.w3.org/2022/08/17-wot-td-minutes.html kaz 15:55:59 s/@@@/kaz: please check with Lagally and make sure the edit by PR 1558 is OK by him too./ 15:56:02 rrsagent, draft minutes 15:56:02 I have made the request to generate https://www.w3.org/2022/08/17-wot-td-minutes.html kaz