14:01:30 <RRSAgent> RRSAgent has joined #wot-td
14:01:30 <RRSAgent> logging to https://www.w3.org/2021/08/04-wot-td-irc
14:01:44 <kaz> meeting: WoT-WG - TD-TF
14:01:53 <kaz> present+ Kaz_Ashimura, Ege_Korkan
14:02:13 <kaz> present+ Michael_McCool
14:02:41 <dape> dape has joined #wot-td
14:04:56 <kaz> present+ Daniel_Peintner
14:06:04 <McCool> McCool has joined #wot-td
14:06:47 <kaz> present+ Cristiano_Aguzzi
14:07:17 <cris> cris has joined #wot-td
14:07:35 <kaz> Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Aug_4.2C_2021
14:08:31 <kaz> present+ Sebastian_Kaebisch
14:09:21 <kaz> present+ Ben_Francis
14:10:01 <sebastian> sebastian has joined #wot-td
14:10:23 <Mizushima> Mizushima has joined #wot-td
14:11:03 <kaz> scribenick: benfrancis
14:12:51 <kaz> present+ Tomoaki_Mizushima
14:12:52 <McCool> https://github.com/w3c/wot-thing-description/issues/1001
14:13:00 <benfrancis> sebastian: Welcome to the call, we will look at some PRs and issues and discuss publication.
14:13:03 <McCool> https://github.com/w3c/wot-thing-description/pull/1155
14:13:36 <benfrancis> topic: Minutes from last time
14:14:07 <kaz> -> https://www.w3.org/2021/07/28-wot-td-minutes.html July-28
14:20:02 <benfrancis> Resolution: minutes approved
14:20:15 <benfrancis> Topic: Publication Plans
14:20:52 <benfrancis> The Working Group Charter has been extended for another six months, until the end of January, by which point we should have released recommendation documents.
14:21:25 <benfrancis> sebastian: CR in November, PR in December, REC in February. Dates provided by W3C calculator.
14:22:12 <kaz> q+
14:22:35 <benfrancis> sebastian: Should publish candidate recommendation in October so we have more time for updates if neede.
14:22:55 <dape> s/if neede/if needed
14:23:10 <benfrancis> sebastian: I suggest we should spend all of September to implement missing features for TD 1.1, then work on Candidate Recommendation in October.
14:23:25 <benfrancis> sebastian: Then proposed recommendation, then recommendation next year.
14:23:54 <benfrancis> kaz: Working Group Charter lasts until January next year. If we need to we can ask for an extension.
14:24:20 <benfrancis> sebastian: I understand, so we are not yet in an extension of the Working Group charter.
14:25:00 <kaz> i|understand|-> https://www.w3.org/2020/01/wot-wg-charter.html current WoT WG Charter|
14:25:27 <benfrancis> sebastian: Suggest implementing all missing features for TD 1.1 in September, then plan for a CR in October.
14:25:38 <benfrancis> kaz: Tough, but would be nice
14:25:57 <benfrancis> sebastian: Yes, we will need time for testing.
14:26:15 <benfrancis> Topic: Pull Requests
14:26:42 <benfrancis> Subtopic: PR 1155
14:26:42 <benfrancis> https://github.com/w3c/wot-thing-description/pull/1155
14:27:09 <benfrancis> Draft Testing Report for TD 1.1
14:28:01 <benfrancis> There were some errors that showed up. Flagged some assertions that weren't right. Need fixing in spec.
14:28:09 <benfrancis> Basically a reorganisation, updates the report as a draft.
14:28:44 <benfrancis> sebastian: Why have so many files changed?
14:29:24 <benfrancis> McCool: Mostly because this is a re-rendering. New files resurrected from old branch and put in the archive. Technically not needed because they are in branch but people kept worrying where they were.
14:29:35 <benfrancis> sebastian: I propose that we merge to have a rendered version.
14:30:16 <benfrancis> Resolution: Will merge PR 1155
14:30:24 <benfrancis> sebastian: Thank you for working on this, not easy.
14:30:49 <benfrancis> McCool: Sorry it took so long, still work to do. In particular testing implementations, need descriptions from each implementer to say what they worked on.
14:32:07 <benfrancis> McCool: Should add issues about adding organisations, e.g. WebThings
14:32:21 <benfrancis> sebastian: Would be good to have WebThings here.
14:32:25 <benfrancis> benfrancis: Sounds good
14:32:39 <benfrancis> sebastian: Can see gaps.
14:32:55 <benfrancis> Ege: Gaps could also be that there is no test.
14:32:59 <benfrancis> Ege: How do we know?
14:33:06 <benfrancis> McCool: If there are zero failures then there is no test.
14:33:50 <benfrancis> McCool: Currently only need one result for optional features, decided we now need two implementations for optional implementations. That may cause more failures. Everything that is currently a 1 will be red.
14:34:58 <benfrancis> Ege: There is a TD default observeable. Manual assertion, newly added. Somehow it has 4 implementations which all pass.
14:35:11 <benfrancis> McCool: I think right now that's a manual assertion and people have submitted it as true.
14:35:23 <benfrancis> Ege: Shouldn't be, I didn't even add this to a template.
14:35:34 <benfrancis> McCool: Consumer assumes that it has a value false.
14:35:48 <benfrancis> Ege: I added this assertion to the TD spec last week, there is something wrong somewhere.
14:35:57 <benfrancis> McCool: Could check ID values, could be duplicates.
14:36:01 <benfrancis> McCool: Let's investigate.
14:36:17 <benfrancis> McCool: If you look at the output.log it flags a bunch of errors that need fixing.
14:37:51 <benfrancis> sebastian: For the next testfest, concentrate on gaps
14:37:58 <benfrancis> sebastian: Should definitely be discussed in the testing call
14:38:10 <benfrancis> McCool: I will try to clean up more if I can, but this is a starting point
14:38:45 <benfrancis> sebastian: Thanks for the effort, first version of 1.1 test report. Will continue to work on it to fill gaps.
14:40:35 <benfrancis> Subtopic: Add "precision" to data schema #1001
14:40:38 <benfrancis> https://github.com/w3c/wot-thing-description/issues/1001
14:40:51 <benfrancis> McCool: Three different terms: Precision, resolution and accuracy.
14:41:21 <benfrancis> McCool: Wrote draft for editor's note.
14:42:11 <benfrancis> Need to figure out where in the spec to put this
14:42:25 <benfrancis> Take a look and let me know if this makes sense
14:42:50 <benfrancis> sebastian: I like the idea of recommending a particular ontology which defines this expression
14:43:14 <benfrancis> McCool: I think what we want is a data schema, parallel to multipleOf. Used in a data schema to annotate particular values.
14:43:51 <benfrancis> Something like { "ssn:accuracy": 5, "ssn:precision": 10 }
14:43:58 <benfrancis> What about units?
14:44:37 <benfrancis> { "type": "number", "multipleOf": 1 }
14:45:11 <benfrancis> Have seen examples when precision/accuracy given in different units to main value, e.g. if there's a big difference in size of values.
14:45:29 <benfrancis> For now the example doesn't have to mention units, but something to discuss when discussing units
14:45:45 <sebastian> q+
14:45:50 <kaz> q-
14:46:13 <benfrancis> Ege: Should at least be able to have precision and accuracy bigger than...
14:46:19 <benfrancis> the value
14:46:45 <benfrancis> McCool: Might argue that precision lower than accuracy. Think they should be larger.
14:47:03 <benfrancis> Discussing graph in https://github.com/w3c/wot-thing-description/issues/1001#issuecomment-884234374
14:47:51 <sebastian> I have to open the door...
14:47:55 <benfrancis> McCool: Issue of probability of being within certain distance. Give default value like 90%
14:48:14 <benfrancis> Ege: Does anything limit anyone from putting an object as a value for accuracy
14:48:35 <benfrancis> McCool: Why would you want an object for accuracy?
14:48:43 <benfrancis> Ege: Just asking if it is valid
14:48:51 <benfrancis> McCool: Gets to the issue of how do we validate extensions?
14:49:06 <benfrancis> Do we want to define something in our own JSON Schema which validates these terms?
14:49:15 <benfrancis> We could include these definitions in our own ontology.
14:50:12 <benfrancis> cris: The validation of this extension is quite tricky. Prefixes that could change. JSON Schema for that is hard unless we embed them in our ontology. Should also ask whether plans to add prefix support.
14:50:35 <benfrancis> McCool: Ours is JSON-LD so we're allowed to use prefixes, but they may not be consistent so hard to validate. If we put them in our ontology then we can check them.
14:51:02 <benfrancis> If it's an object, what if I want to do type object? Think should require separate for each member, more logical.
14:51:08 <benfrancis> Makes it more verbose.
14:51:36 <benfrancis> McCool: What does multipleOf do? If can be used on objects then would be OK.
14:52:39 <benfrancis> Ege: I really meant what if someone makes a mistake by putting an object in the value.
14:52:51 <benfrancis> McCool: Ideally the validator would catch that. Can add to validator if part of ontology.
14:53:08 <benfrancis> More in line with mlagally's original proposal of having these built in.
14:53:24 <benfrancis> Maybe we can ask the SDF people as well.
14:53:53 <benfrancis> Ege: Ontologies are growing, when should we say yes and when should we say no? If only benefit is easier validation...
14:54:03 <benfrancis> McCool: Putting in our own ontology also helps with consistency.
14:55:07 <benfrancis> cris: Importing the entire SSN ontology is a big deal, it's huge.
14:55:43 <benfrancis> I was comfortable with the text you wrote, encouraging people to use SSN.
14:55:59 <benfrancis> McCool: I like this suggestion of adding a new section. Then can add as a starting point.
14:56:33 <benfrancis> sebastian: Makes sense, chapter about making use of external ontologies, can provide context about precision and show how it can be implemented in SSN.
14:56:48 <benfrancis> Makes sense to have examples there and provide a good explanation.
14:57:19 <benfrancis> McCool: Create a new section, not an editor's note, change highly recommended to SHOULD, include example. Will create a PR for this shortly.
14:57:56 <benfrancis> (McCool leaves)
14:58:22 <benfrancis> Subtopic: Security reorder #1201
14:58:26 <benfrancis> https://github.com/w3c/wot-thing-description/pull/1201
14:58:35 <benfrancis> sebastian: IIRC McCool suggested merging this PR.
14:59:36 <benfrancis> Will merge, mccool will review before.
14:59:51 <benfrancis> Resolution: Merge.
15:00:02 <benfrancis> Subtopic: Fix definition of multipleOf in TD schema #1204
15:00:05 <benfrancis> https://github.com/w3c/wot-thing-description/pull/1204
15:00:26 <benfrancis> May need to make Jan an Invited Expert as he is making good contributions
15:00:55 <benfrancis> sebastian: Problem with definition of multipleOf in JSON schemas
15:01:24 <benfrancis> Looks OK, Ege can explain what is wrong.
15:02:00 <benfrancis> Ege: I think it was more in the TM that there was a problem. In the TD he only re-factors it. In the TM schema...
15:02:29 <benfrancis> sebastian: oneOf -> anyOf. Global definition. Re-use definition in different places in JSON Schema
15:03:02 <benfrancis> Ege: I approved it, OK for me.
15:04:01 <kaz> q+
15:04:05 <benfrancis> sebastian: I am fine to merge this PR, but still have the consideration that Jan is not a member. kaz should decided what to do. Member or Invited Expert? He is a student at university.
15:04:11 <sebastian> ack s
15:04:30 <benfrancis> kaz: As usual, if this content is editorial we can simply merge it. If it is normative content we should consider making him an Invited Expert.
15:04:47 <benfrancis> sebastian: I can ask him if he is interested in being an Invited Expert, and suggest that he applies.
15:04:59 <benfrancis> sebastian: Is it OK to merge this since it's just a bugfix?
15:05:07 <benfrancis> kaz: Yes we can mark this as editorial.
15:05:45 <benfrancis> (kaz marks the PR as non-substantive for IPR)
15:06:46 <benfrancis> Resolution: Merge the PR, invite @JKRhb to be an Invited Expert.
15:07:41 <benfrancis> Subtopic: Fix issues in TM schema generation script #1205
15:07:44 <benfrancis> https://github.com/w3c/wot-thing-description/pull/1205
15:07:47 <benfrancis> sebastian: Not ready to merge?
15:07:54 <benfrancis> Ege: I need to review this, not had time yet
15:08:09 <benfrancis> Subtopic: WIP: Updates for TM Chapter #1207
15:08:12 <benfrancis> https://github.com/w3c/wot-thing-description/pull/1207
15:08:40 <benfrancis> WIP PR removing text about TMs, clarification about overwriting, TM composition with links, unclear assertion on TMS.
15:08:47 <benfrancis> Topic: Issues
15:09:13 <benfrancis> Subtopic: Add "precision" to data schema #1001
15:09:16 <benfrancis> https://github.com/w3c/wot-thing-description/issues/1001
15:09:20 <benfrancis> Already discussed above
15:09:32 <benfrancis> Subtopic: Should it be possible to indicate whether writing a property returns set value? #875
15:09:35 <benfrancis> https://github.com/w3c/wot-thing-description/issues/875
15:10:43 <benfrancis> dape: Questions about response/return types
15:11:03 <benfrancis> dape: Whether a return value is expected, could be introduced easily without breaking anything
15:11:09 <cris> q+
15:11:13 <kaz> q=
15:11:16 <kaz> q-
15:11:21 <kaz> s/q=//
15:11:49 <benfrancis> sebastian: Relates to PUT vs. POST operation
15:11:55 <benfrancis> q+
15:12:16 <benfrancis> sebastian: Same expectation as reading a property?
15:12:37 <benfrancis> Ege: What if I return something?
15:12:51 <benfrancis> dape: If write a large blob, in some cases don't want to return the whole blob
15:13:02 <benfrancis> dape: Need to have a way to indicate whether something comes back
15:13:31 <benfrancis> sebastian: If there's a big payload, would be strange for it to be returned. Could be possible, not mandatory, open to implemtnation
15:13:31 <dape> q?
15:13:35 <sebastian> q?
15:13:43 <kaz> ack c
15:14:32 <benfrancis> cris: I agree it would be easier to introduce the feature if we say we allow returning the exact type in input. E.g. in Philips Hue case where they return an object, the protocol binding should do the work.
15:15:44 <benfrancis> cris: Protocol dependent feature. Some ambiguity.
15:15:50 <dape> q?
15:15:56 <benfrancis> (Sorry, missed some points)
15:17:23 <benfrancis> benfrancis: We discussed this in WoT Profile, decided not to return the value since it could be very large.
15:18:25 <kaz> q+
15:18:55 <cris> dape: in this scripting api currently we return void. The echonet people would expect having a value back, it feels that we are not fully compliant with them
15:19:08 <Ege> q+
15:19:19 <sebastian> ack b
15:19:24 <sebastian> ack k
15:19:39 <cris> ... also I found a possible use case to know from the application side the real floating point value written. For example, I'll try to write 1.3333 and the device actually store 1.33
15:20:08 <cris> kaz: daniel are you referring to the old document from Echonet?
15:20:15 <cris> dape: yes
15:20:21 <cris> kaz: there is an update
15:20:51 <benfrancis> kaz: We should wait for ECHONET discussion.
15:20:58 <benfrancis> (Thanks cris!)
15:21:41 <benfrancis> dape: During discussion in WoT Profile discussion the initial proposal was to return a value. It is used out there and currently in the TD we can't describe it.
15:22:46 <benfrancis> kaz: Need more use cases for proposed interface. Look at industry use cases, existing devices and standards including Philips Hue, ECHONET, OPC-UA etc.
15:23:03 <benfrancis> Don't need work on new profiles, but should look at existing industry standards or proprietary interfaces.
15:23:20 <kaz> s/Don't/... Don't/
15:23:29 <kaz> q?
15:23:33 <kaz> ack e
15:24:04 <benfrancis> Ege: I think we are mixing prescriptive and descriptive approaches. Whether we say you should describe one or the other, it doesn't matter. The important thing is that we can describe either scenario.
15:24:56 <sebastian> ack e
15:25:07 <benfrancis> Ege: Philips Hue is very popular, we should be able to describe its API.
15:25:42 <benfrancis> Currently have to use actions because modelling as properties is complicated.
15:25:50 <kaz> s/need work on/need to work on/
15:26:06 <benfrancis> The object that you read is different to the object you write, the write returns another type of object which is completely different.
15:26:37 <kaz> i/in this scripting/scribenick: cris/
15:26:54 <kaz> i/We should wait/scribenick: benfrancis/
15:27:30 <kaz> s/Currently/... Currently/
15:27:37 <kaz> s/The object/... The object/
15:27:37 <benfrancis> sebastian: writeResponse tells client/consumer whether you are getting a response. true/false.
15:27:44 <benfrancis> Ege: Would work for Philips Hue.
15:27:53 <kaz> rrsagent, make log public
15:27:56 <kaz> rrsagent, draft minutes
15:27:56 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/04-wot-td-minutes.html kaz
15:28:08 <benfrancis> If default assumptions not true then need to provide a data schema at the forms level.
15:28:29 <kaz> s/If default/... If default/
15:28:51 <benfrancis> q+
15:30:00 <kaz> chair: Sebastian
15:30:02 <kaz> rrsagent, draft minutes
15:30:02 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/04-wot-td-minutes.html kaz
15:30:15 <benfrancis> benfrancis:
15:30:19 <benfrancis> https://w3c.github.io/wot-thing-description/#form
15:30:45 <benfrancis> benfrancis: Form has a response member, is that not what this is for?
15:31:45 <kaz> s/kaz: there is an update//
15:31:46 <benfrancis> benfrancis: If ExpectedResponse has a schema member, does this not solve the problem?
15:32:10 <benfrancis> benfrancis: schema in ExpectedResponse also needed for actions
15:33:02 <benfrancis> dape: In case of action separate input and output schemas
15:33:15 <benfrancis> benfrancis: If an ExpectedResponse has schema then could put it there
15:33:32 <kaz> s/kaz: We should wait for ECHONET discussion./kaz: Regarding the ECHONET collaboration, we got some latest updates from Matsuda-san, and got a new use case description yesterday. So we should wait for further clarification on their interfaces based on the collaborative discussion./
15:34:35 <benfrancis> cris: I think this would cover the three cases that you wrote
15:35:12 <benfrancis> Ege: Need defaults, e.g. if detect different data in response.
15:35:29 <benfrancis> cris: If we leverage schema term, we cover all sebastian's use cases without writeResponse term.
15:35:42 <benfrancis> A little concerned from the implementation point of view.
15:35:48 <benfrancis> What if we have forms with differnet schemas
15:36:11 <benfrancis> E.g. in actions, should always use the schema inside the form
15:37:31 <benfrancis> benfrancis: with schemaDefinitions proposal, possible to describe complex APIs, but not clear a Consumer would actually be able to communicate with a device.
15:37:38 <benfrancis> cris: Yes, exactly my point.
15:39:26 <benfrancis> benfrancis: Important point is that the schema term needs adding to the ExpectedResponse object to make the three cases possible.
15:39:59 <benfrancis> benfrancis: Whether a consumer can interpret this is another matter, would be interested to see how implementations cope with this.
15:40:58 <benfrancis> dape: The runtime can choose. Need to detect whether anything comes back. In the simple case maybe there's one return value that's always the same. If there are variations between forms then it becomes hacky.
15:41:25 <benfrancis> cris: Just started working on validation of inputs and outputs. So far fine, but once need to merge schemas and deal with schemas at different levels it will get messy. Just a feeling.
15:41:47 <benfrancis> sebastian: Homework for you to describe in Scripting API and evaluate what this looks like. Then make a decision based on that.
15:42:02 <benfrancis> dape: In the current case don't expect a response, and can still do so.
15:42:21 <benfrancis> If interested in the result then have a more complex use case and the implementation becomes more complex.
15:42:32 <benfrancis> Ege: Not just an API problem, also hard for a human to do.
15:42:54 <benfrancis> Should they put details in each Form? Decide whether the value being returned is valuable for business logic?
15:43:35 <benfrancis> Generally feels like a bad design that means I have to look into this stuff. Need to push it up to the application level in some cases because not clear what to do with the schema, not clear what is important for application logic.
15:44:37 <benfrancis> cris: Maybe I can describe the flow if this was introduced to Scripting API. If developer writing application wants these values, first need to search for the forms that provide this value. Need to look for a form with conforms with criteria looking for. After choosing form, tells the runtime to use the form. The runtime could choose not to use
15:44:37 <benfrancis> that form index. Runtime could choose another form.
15:45:03 <benfrancis> dape: If the form index is provided, it's not just a hint. If the form doesn't work then you provide an error.
15:45:30 <kaz> s/Should they put d/... Should they put d/
15:45:41 <kaz> s/Generally feels/... Generally feels/
15:45:54 <benfrancis> sebastian: Don't know how to proceed here.
15:45:57 <kaz> s/that form/... that form/
15:46:01 <kaz> rrsagent, draft minutes
15:46:01 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/04-wot-td-minutes.html kaz
15:46:42 <benfrancis> benfrancis: Could resolve to add schema member to ExpectedResponse and then see how well it works in practice in implementations.
15:46:51 <benfrancis> cris: Yes I think implementations will be the decider.
15:47:03 <benfrancis> dape: Could add the feature but mark it as at risk.
15:47:59 <benfrancis> sebastian: Introducing schema in ExpectedResponse also motivated by the queryaction issue. Should introduce it. A bit of a contradition that it's in AdditionalExpectedResponse but not ExpectedResponse.
15:49:06 <benfrancis> benfrancis: In case of actions about separating schema of output of action from the schema of the response to the request.
15:49:47 <kaz> q+
15:50:06 <kaz> ack b
15:50:32 <sebastian> q?
15:51:02 <benfrancis> kaz: OK with adding this, but as usual would be nice to have more concrete code and to let people know how to use this feature, with what kind of device and device transfer.
15:51:19 <benfrancis> sebastian: This is also a nice feature for ECHONET since we can describe how it works today
15:51:38 <benfrancis> kaz: ECHONET is still delicate, can assume something based on old specification.
15:51:42 <benfrancis> q+
15:51:46 <Ege> q+
15:51:58 <kaz> ack k
15:52:38 <benfrancis> benfrancis: Core Profile is a potential use case
15:53:47 <benfrancis> kaz: Should clarify how to use these features/binding somewhere. For the moment putting it in the WoT Profile document is fine. Would be nice to have description within the implementation guideline document separately.
15:55:46 <benfrancis> kaz: Can think about Philips Hue/OPC-UA as industry examples. Should clarify how to use features in actual use cases and document it somewhere.
15:56:26 <kaz> q?
15:56:29 <benfrancis> Resolution: Introduce schema term in ExpectedResponse. Declare it as "at risk" and ask for implementations.
15:56:54 <benfrancis> sebastian: Who can introduce this feature? cris?
15:57:02 <benfrancis> cris: I will look into this. I also need to check with node-wot.
15:57:21 <sebastian> q?
15:57:46 <benfrancis> Ege: MindSphere API provides another example.
16:02:16 <benfrancis> sebastian: Please provide feedback on How do you cancel or query the state of an action request? #302 https://github.com/w3c/wot-thing-description/issues/302
16:02:28 <benfrancis> Encourage Ege to discuss this issue next week and take a decision
16:06:15 <benfrancis> Ege: Raises topic of asynchronous decision making, from Ben's email
16:06:35 <benfrancis> sebastian: A chair has to be present to merge a PR
16:06:42 <benfrancis> kaz: This is up to group, chairs can delegate
16:06:53 <kaz> q+
16:07:14 <benfrancis> benfrancis: Current decision policy favours asynchronous decision making
16:08:54 <benfrancis> sebastian: I can leave comments on issues that I think are ready to land before I leave
16:08:57 <kaz> ack b
16:08:58 <kaz> ack e
16:08:59 <kaz> ack k
16:09:09 <kaz> [adjourned]
16:09:14 <kaz> rrsagent, draft minutes
16:09:14 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/04-wot-td-minutes.html kaz