14:00:03 <RRSAgent> RRSAgent has joined #wot-arch
14:00:03 <RRSAgent> logging to https://www.w3.org/2021/09/09-wot-arch-irc
14:01:53 <kaz> meeting: WoT Architecture
14:02:12 <kaz> present+ Kaz_Ashimura, Michael_McCool, Michael_Koster
14:02:34 <mjk> mjk has joined #wot-arch
14:03:43 <kaz> present+ Michael_Lagally
14:04:49 <mlagally> mlagally has joined #wot-arch
14:06:26 <kaz> present+ Sebastian_Kaebisch
14:06:59 <kaz> Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Sept_9th.2C_2021
14:07:06 <kaz> present+ Ben_Francis
14:07:43 <Mizushima> Mizushima has joined #wot-arch
14:09:08 <kaz> present+ Tomoaki_Mizushima
14:11:03 <McCool> McCool has joined #wot-arch
14:12:19 <kaz> scribenick: McCool
14:12:19 <McCool> topic: minutes
14:12:32 <kaz> -> https://www.w3.org/2021/07/29-wot-arch-minutes.html July-29
14:12:32 <McCool> review 07-29 minutes
14:13:04 <McCool> any objections?
14:13:13 <McCool> hearing none, minutes are approved
14:13:26 <McCool> topic: profile pull 96
14:13:38 <McCool> canonical TD dependencies
14:14:09 <McCool> ... removing the dependency on canonical TDs and replace it with defaults instead
14:15:03 <McCool> bf: small change to avoid using canonical TD, since *all* we want to do is apply defaults, not the other changes
14:15:48 <McCool> bf: there is some other HTML cleanup though that makes the diff bigger
14:15:56 <kaz> i|canonical|-> https://github.com/w3c/wot-profile/pull/96 PR 96 - Remove Canonical TD dependency from property binding|
14:16:07 <kaz> s/canonical/ml: canonical/
14:16:27 <McCool> ml: suggest we merge; any objections?
14:16:47 <McCool> ... will merge
14:16:54 <McCool> topic: pull 93
14:17:04 <McCool> reworking data model section
14:17:40 <McCool> has some detailed feedback on every section
14:18:32 <benfrancis> q+
14:18:32 <McCool> q+
14:19:01 <McCool> ml: don't feel that interop conflicts with readability and constrained devices
14:19:15 <kaz> i|reworking|-> https://github.com/w3c/wot-profile/pull/93 PR 93 - reworking data model section|
14:19:17 <McCool> bf: conflicts between readability and constrained devices
14:19:24 <kaz> s/reworking/ml: reworking/
14:19:27 <McCool> ... core profile is not specifically for constrained devices
14:19:29 <kaz> s/has some/... has some/
14:19:43 <McCool> ... and http profile is not really appropriate for constrained devices
14:19:46 <kaz> rrsagent, make log public
14:19:50 <kaz> rrsagent, draft minutes
14:19:50 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/09-wot-arch-minutes.html kaz
14:20:54 <McCool> mm: I think this should just say the goal is to "improve interoperability"
14:22:03 <McCool> seb: interop also contains readability implicitly
14:22:52 <McCool> mm: not necessarily, there are cases where it is in conflict
14:23:14 <McCool> ... for example, to avoid ambiguity, we might have to make the TD more verbose, which is in conflict with readability
14:24:10 <McCool> ml: I think we also want so say something about simplified processing
14:24:23 <benfrancis> q+
14:24:31 <McCool> ack m
14:24:44 <kaz> q?
14:25:09 <McCool> mm: simplified processing is a secondary goal, at best
14:25:27 <McCool> bf: however, this discussion comes after my PR which just removes this section
14:25:47 <McCool> ... so we should perhaps discuss whether we need this section before trying to wordsmith it
14:26:43 <McCool> ml: however, I think there are several things in this section that we do need, such as length limits
14:26:55 <benfrancis> q+
14:26:56 <McCool> ... in order to align with other ecosystems that have such limits
14:27:40 <McCool> bf: I did a line by line explanation on why I think *each* of these is unnecessary; Ege agreed
14:27:52 <McCool> ... is there a specific point that you disagree with?
14:28:25 <McCool> q+
14:28:30 <McCool> ack b
14:30:12 <McCool> ack m
14:30:36 <McCool> mm: would like to see if we can resolve this; this is a set of constraints, we really should consider them individually
14:30:43 <McCool> ... then do a wrapper summary last
14:31:07 <McCool> ... conversely we can discuss offline, or on the issue
14:31:32 <McCool> ml: I think we should take this offline for now, review, and revisit next week
14:31:57 <mlagally> q?
14:32:11 <McCool> ml: as an aside I want to point out that the sections align with those in the TD, which I think is a reasonable structure
14:32:24 <McCool> topic: pull 91 - TD examples
14:32:47 <McCool> ml: do we still want to use a canonical TD here?
14:33:14 <kaz> i|do we|-> https://github.com/w3c/wot-profile/pull/91 PR 91 - Example TD and canonical TD for Core Profile - closes #90|
14:34:16 <McCool> bf: the idea here is to write some examples that use each of the operations, using a common web thing
14:34:43 <McCool> ... end is a longer thing description, which I've called a "Canonical TD" (maybe wrong term), but applies all the defaults
14:35:24 <McCool> ... however, this PR is still a draft, since actions are under discussion in the TD spec, including new ops
14:36:13 <McCool> ml: if I recall we decided only to provide a subset of operations
14:37:12 <McCool> bf: this PR is a draft, suggest skipping this one for now, coming back to it later once we have resolved other PRs
14:37:26 <McCool> ml: does the second example add value?
14:37:51 <McCool> bf: idea is the first one is the simplified TD, the second one is how it should be interpreted (e.g. after defaults are applied)
14:38:38 <kaz> q+
14:38:53 <McCool> mm: I think the second one is useful, and could be called "Expanded form" rather than Canonical Form
14:39:10 <McCool> ml: why do we need the first one there?
14:39:49 <McCool> bf: the idea is the first one is the simplified form
14:40:02 <McCool> mm: these are a pair, they only make sense together
14:40:27 <McCool> ... they are the same TD, just in different forms
14:40:29 <benfrancis> q+
14:41:09 <McCool> ml: worried that there are things in the example that are not well explained in the text
14:41:29 <McCool> mm: perhaps can raise specific issues about things that might be in the example but are not described in normative text
14:41:55 <McCool> kaz: think examples are good, but perhaps can structure the sections better
14:42:16 <McCool> ml: I think both belong in section 5.3
14:42:51 <McCool> bf: nothing in the example that are not in the text; is non-normative, which is an overview
14:43:07 <McCool> ... have no problem putting both examples in the same section
14:43:27 <McCool> ... with regards to external TD section, I'm proposing we remove that section
14:43:51 <McCool> ... and I explain my thoughts about that in the restructuring PR
14:44:04 <McCool> ... I think we should look at the protocol binding section
14:44:11 <McCool> s/section/pr/
14:44:14 <kaz> rrsagent, make log public
14:44:18 <kaz> rrsagent, draft minutes
14:44:18 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/09-wot-arch-minutes.html kaz
14:44:49 <McCool> topic: pull 89 - actions
14:45:02 <kaz> chair: Lagally
14:46:25 <kaz> -> https://github.com/w3c/wot-profile/pull/89 PR 89 - Define protocol binding for actions - closes #81
14:47:11 <McCool> ml: discussion of situation where cancel action takes longer than the timeout
14:48:12 <benfrancis> q+
14:48:17 <kaz> ack k
14:48:22 <McCool> bf: (feedback in issue; simple for simple cases; edge cases can use a different approach, e.g. a separate cancel action)
14:48:48 <McCool> bf: we have an existing protocol binding for profiles
14:49:04 <McCool> ... it's also not defined if a writeproperty takes longer than the time
14:49:09 <McCool> ... what do we do then?
14:49:24 <McCool> ml: an HTTP timeout error occurs
14:49:47 <McCool> ... so if that happens with a timeout, how do we see whether or not the action got cancelled?
14:50:13 <McCool> bf: same problem with a property; you would have to read the value
14:50:24 <McCool> ... for actions, we would have to check the status
14:50:28 <McCool> q+
14:52:27 <McCool> mccool: I think that as long as we can query the status of an action, then there is an error recovery mechanism
14:52:40 <McCool> ... then can repeat the cancel
14:53:20 <kaz> q?
14:53:24 <kaz> ack b
14:53:25 <McCool> ... if we EXPECT cancels to take a long time, can have a separate async action as ben sugests
14:53:26 <kaz> ack m
14:53:39 <kaz> q+
14:54:42 <McCool> bf: we could also add a "cancel" state... but since the resource gets deleted, checking to see if the resource is gone is enough
14:54:57 <McCool> mm: think we should add some explanatory text for error recovery recommendations
14:56:32 <McCool> kaz: should define something polite for recovery
14:57:03 <kaz> s/recovery/recovery as our recommendation/
14:57:17 <McCool> mm: for example, should wait a while and not send a bunch of new cancellations immediately, since if the server was slow to respond it might just be busy
14:57:20 <kaz> ack k
14:57:31 <McCool> ... in which case sending more requests is not helpful
14:57:55 <McCool> bf: several places where error-recovery suggestions would be good, but let's not block the current issue
14:57:58 <McCool> ml: concur
14:58:21 <McCool> seb: any updates due to the name conventions discussed in the TD call?
14:58:29 <kaz> s/recommendation/recommendation, though doing too much would be a kind of DOS/
14:58:54 <McCool> bf: just headings, so I suggest we land this, then revisit one we finish discussing the naming conventions
14:59:17 <McCool> seb: happy with merging this PR, I think it is a good baseline, and good to have in the profile
14:59:35 <McCool> ml: one change requested, will approve so can merge
14:59:47 <McCool> ... any final problems with merging this?
14:59:57 <McCool> ... hearing none, merging.
15:00:33 <McCool> topic: pull 94 - date and time formats
15:02:47 <McCool> mm: why do we have the SHOULD for UTC?  What is the purpose?
15:03:09 <McCool> ... MUST would simplify processing, but SHOULD does not help there
15:06:21 <Mizushima> Mizushima has joined #wot-arch
15:06:21 <kaz> i|why do we|-> https://github.com/w3c/wot-profile/pull/94 PR 94 - time format - initial draft|
15:09:54 <McCool> ml: after discussion... will make UTC with Z mandatory
15:12:37 <kaz> -> https://en.wikipedia.org/wiki/ISO_8601 FYI, ISO 8601
15:13:46 <McCool> mm: also corner case with 24:00 and fractional seconds, see TD spec for canonical form
15:13:56 <McCool> topic: pull 92
15:14:06 <McCool> define protocol binding for events
15:14:25 <McCool> bf: reached resolution in the last call to add a local biblio entry
15:14:33 <McCool> ml: which one are we using?
15:14:39 <McCool> ... the WHATWG spec
15:15:03 <kaz> q+
15:15:12 <McCool> ml: is that subject to change?
15:15:27 <McCool> m: we could always cite the spec as of a specific date
15:15:49 <McCool> bf: respec says should fix the ref in spec
15:16:27 <kaz> i|define|-> https://github.com/w3c/wot-profile/pull/92 PR 92 - Define protocol binding for events - closes #42|
15:16:37 <kaz> s/define pro/ml: define pro/
15:17:05 <kaz> s/m:/mm:/
15:17:06 <McCool> mm: used to be a way to send updates, but I have not been able to find it lately
15:17:21 <McCool> ... also, I think it is ok to override if necessary
15:17:59 <McCool> bf: I should mention these are basically identical
15:19:19 <McCool> mm: so referencing the W3C version accomplishes the same goal as freezing at the current spec
15:19:58 <McCool> s/current/current WHATWG spec/
15:20:09 <McCool> s/spec spec/spec/
15:20:45 <McCool> kaz: talked to PLH about this, they suggested using the WHATWG spec
15:21:35 <McCool> ml: but... how do we get a URL for the spec on a current date?
15:22:13 <McCool> mm: is there a URL format or an archive to refer to dated versions?
15:23:09 <McCool> ... this is also needed for W3C living standards, btw
15:26:28 <kaz> kaz: this is a common problem, so would suggest we talk with PLH and Ralph again
15:27:18 <McCool> mm: suggest we merge as is (with the WHATWG ref) then create an issue to resolve this (e.g. by referring to dated WHATWG spec, updating the respec database, etc)
15:28:04 <McCool> ml: ok, let's do that, and I will create an issue to update the reference
15:31:38 <McCool> ... (creates wot-profile issue to reference stable version of SSE)
15:37:02 <McCool> mm: never mind, I looked it up and WHATWG explicitly says snapshots are non-authoritative
15:37:16 <McCool> ... so it still looks like using the W3C version is our best approach
15:37:23 <McCool> bf: done; reverted
15:37:30 <McCool> topic: pull 92
15:37:34 <McCool> events
15:37:58 <McCool> ml: let's look at subscribe events
15:39:22 <benfrancis> q+
15:39:51 <kaz> ack k
15:40:09 <McCool> mm: limit is an issue, if there is one, it should be a lower bound
15:40:22 <McCool> bf: minimum number comes from web browser
15:40:32 <McCool> ... this is implementation specific, however
15:41:04 <McCool> ... and implementors may not be able to honor a higher limit, it is out of their control
15:42:55 <McCool> ... and it's possible they will change over time
15:43:05 <McCool> ... so a specific limit is dangerous
15:43:21 <McCool> mm: better then to just deal with this as an error condition
15:43:22 <kaz> i|events|-> https://github.com/w3c/wot-profile/pull/92 PR 92 - Define protocol binding for events - closes #42|
15:43:34 <McCool> ml: could add a note about limits, perhaps?
15:43:37 <kaz> s/events/ml: events/
15:43:47 <McCool> bf: constraint is on the client side, not the server side
15:44:05 <McCool> ... all our errors are server side
15:46:00 <McCool> mm: and I can think of scenarios where a server might want to support 1000s of subscribers
15:46:10 <McCool> ... not clear what kind of limit makes sense in all use cases
15:47:35 <McCool> ml: so what kind of error makes sense?  500?
15:47:56 <McCool> ... is 500 a last resort?
15:48:09 <McCool> bf: 503, service not available
15:48:23 <McCool> mm: should we look at all the codes and see what's appropriate?
15:49:04 <McCool> bf: in practice, people will use a library and the library will return its own code
15:50:10 <McCool> bf: in practice people use large error classes
15:50:18 <McCool> mm: and the scripting API does that too
15:50:29 <kaz> -> https://en.wikipedia.org/wiki/List_of_HTTP_status_codes FYI, HTTP status codes
15:53:55 <McCool> bf: problem is if we specify a particular error code and the library does not do that, it will cause implementation pain
15:54:42 <McCool> bf: tried a lot of libraries, not all of them worked; spec is not difficult to implement using raw HTTP
15:55:43 <McCool> mm: what does the actual SSE spec say?
15:56:25 <McCool> ... it gives a set of error codes, but is there one specifically for a failed subscription?
15:56:39 <McCool> ... I think we can ignore errors on the client side...
15:57:17 <McCool> ml: let's look at the spec
15:57:31 <McCool> ... API and protocol need to be lumped together
15:57:40 <McCool> ... which parts do people have to implement?
15:58:12 <McCool> bf: we just require the protocol, not the API
15:58:36 <McCool> ... but the way the spec is written, hard to reference just the protocol
15:59:39 <kaz> i|let's look at the spec|-> Server-Sent Events (Superseded Recommendation)|
15:59:49 <McCool> ml: we can add a chapter ref, e.g. to Chapter 5, when we cite the reference
16:00:27 <McCool> bf: no objections to clarifying which section of the spec we are referring to
16:00:54 <McCool> ... but risky to define new behavior, e.g. new error codes
16:01:39 <McCool> s/new error codes/specified error code/
16:04:35 <McCool> mm: we could just add a line saying the Javascript API does not need to be implemented
16:04:40 <McCool> bf: could do that right now
16:04:52 <McCool> ml: I think we need to do a little more review first
16:07:58 <McCool> mm: I am ok with delegating to ml the decision to merge after ben's update
16:08:42 <McCool> bf: let's also file a separate issue about the error
16:10:43 <McCool> bf: would also like to talk more about async decisions
16:11:15 <McCool> mm: agree, and we were delayed by vacations in august, but we need to discuss this in a broader forum
16:11:28 <McCool> ... will try to bring this up in the main call soon
16:11:41 <kaz> [adjourned]
16:11:47 <kaz> rrsagent, draft minutes
16:11:47 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/09-wot-arch-minutes.html kaz
16:11:48 <McCool> ml: since we are overtime now though we will have to adjourn.  Thanks for all your input!
17:59:04 <Zakim> Zakim has left #wot-arch