Add categorization for TD-related Architecture assertions 19 to 27 #2129
Conversation
JKRhb
force-pushed
the
assertion-categories
branch
from
9487fa3 to
4d2ea0f
Compare
| @@ -75,39 +75,48 @@ Continuation of https://github.com/w3c/wot-thing-description/issues/2120 | |||
|
|
|||
| - [ ] 18. Form fields are optional and MAY further specify the expected request message for the given operation. ([arch-op-expected-request](https://www.w3.org/TR/wot-architecture11/#arch-op-expected-request)) | |||
|
|
|||
| - [ ] 19. Form fields MAY depend on the protocol used for the submission target as specified in the URI scheme. ([arch-op-form-fields-protocol](https://www.w3.org/TR/wot-architecture11/#arch-op-form-fields-protocol)) | |||
| - [x] 19. Form fields MAY depend on the protocol used for the submission target as specified in the URI scheme. ([arch-op-form-fields-protocol](https://www.w3.org/TR/wot-architecture11/#arch-op-form-fields-protocol)) | |||
There was a problem hiding this comment.
We have a race condition ;) See first point at the end of https://pr-preview.s3.amazonaws.com/w3c/wot-thing-description/pull/2123.html#using-a-thing-description-with-a-protocol-binding
There was a problem hiding this comment.
That PR is merged, can be A1.
|
|
||
| - [ ] 21. Protocol Bindings MUST be serialized as hypermedia controls to be self-descriptive on how to activate the Interaction Affordance. ([arch-hypermedia-protocol-binding](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-protocol-binding)) | ||
| - [x] 21. Protocol Bindings MUST be serialized as hypermedia controls to be self-descriptive on how to activate the Interaction Affordance. ([arch-hypermedia-protocol-binding](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-protocol-binding)) |
There was a problem hiding this comment.
Same as above but point 2. both can be reworked to give the exact same meaning
There was a problem hiding this comment.
20 and 21 are in the TD spec now, A1
|
|
||
| - [ ] 22. The hypermedia controls MAY be cached outside the Thing and used for offline processing if caching metadata is available to determine the freshness. ([arch-hypermedia-caching](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-caching)) | ||
| - [x] 22. The hypermedia controls MAY be cached outside the Thing and used for offline processing if caching metadata is available to determine the freshness. ([arch-hypermedia-caching](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-caching)) |
There was a problem hiding this comment.
Not sure if I understand this one
There was a problem hiding this comment.
Yeah, this one is a bit difficult to parse :/
I guess the intention here is simply that if you have a protocol that allows for caching (and determining whether the cache entry is still fresh) you can ... use the data from the cache?
What confuses me a bit is that this assertion talks about caching the hypermedia controls (i.e., the form itself if I see it correctly) which does not make that much sense to me. So maybe we can simply discard this assertion.
There was a problem hiding this comment.
-
Approach 1: Trying harder to understand :D So I understand this in two directions which depends on what "offline processing" refers to.
- It can refer to offline processing of hypermedia controls, i.e. forms, when the Thing is not available. I can for example create (process the hypermedia controls) a script that uses them for an application. Here, caching should mean that the hypermedia controls do not change for a while, e.g., the resource endpoints do not change. In this case, we are talking about very dynamic Things.
- It can refer to the data. E.g., If I know that the temperature does not change for an hour, the Consumer or an intermediary can cache this value and use it an application logic.
I think that the first one makes more sense but this is a case we very rarely see. It can make sense in manageable affordances though.
- Approach 2: Understanding why it is added:
Found it being added at w3c/wot-architecture@7954c31 but it says just a split but it seems it is adding assertions.
Approach 2 seems to fail here
Proposal: I agree with So maybe we can simply discard this assertion. if we don't understand it ourselves as implementers after this long.
There was a problem hiding this comment.
Found it being added at w3c/wot-architecture@7954c31 but it says just a split but it seems it is adding assertions.
Thank you for your researching this, @egekorkan! I am wondering then whether @mkovatsc could help us understand this assertion? Otherwise, I think discarding it should do no harm.
Maybe we could also list/add the use cases you've mentioned somewhere and revisit this topic later, or rather come up with more fitting assertions if appropriate.
There was a problem hiding this comment.
It seems to refer to cases where the Thing Description (specifically the forms) changes dynamically according to the latest state of the Thing (such as its IP address). And I believe the (optional) modified attribute in the TD is provided so that, when cached, one can tell whether the TD is up to date (of course, it’s still necessary to implicitly decide on a TTL somewhere...).
Since the mechanism is covered by the TD document, how about classifying it as category A1?
There was a problem hiding this comment.
Thank you, @k-toumura! A1 would sound good to me then :)
There was a problem hiding this comment.
We talked about it in the TD call and the TF agrees to A1.
egekorkan
added
the
document synchronisation
Sure, will do :) (You mean #2123, right?) Thank you for the review! |
Yup! |
| @@ -75,39 +75,48 @@ Continuation of https://github.com/w3c/wot-thing-description/issues/2120 | |||
|
|
|||
| - [ ] 18. Form fields are optional and MAY further specify the expected request message for the given operation. ([arch-op-expected-request](https://www.w3.org/TR/wot-architecture11/#arch-op-expected-request)) | |||
|
|
|||
| - [ ] 19. Form fields MAY depend on the protocol used for the submission target as specified in the URI scheme. ([arch-op-form-fields-protocol](https://www.w3.org/TR/wot-architecture11/#arch-op-form-fields-protocol)) | |||
| - [x] 19. Form fields MAY depend on the protocol used for the submission target as specified in the URI scheme. ([arch-op-form-fields-protocol](https://www.w3.org/TR/wot-architecture11/#arch-op-form-fields-protocol)) | |||
There was a problem hiding this comment.
That PR is merged, can be A1.
|
|
||
| - [ ] 21. Protocol Bindings MUST be serialized as hypermedia controls to be self-descriptive on how to activate the Interaction Affordance. ([arch-hypermedia-protocol-binding](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-protocol-binding)) | ||
| - [x] 21. Protocol Bindings MUST be serialized as hypermedia controls to be self-descriptive on how to activate the Interaction Affordance. ([arch-hypermedia-protocol-binding](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-protocol-binding)) |
There was a problem hiding this comment.
20 and 21 are in the TD spec now, A1
|
|
||
| - [ ] 22. The hypermedia controls MAY be cached outside the Thing and used for offline processing if caching metadata is available to determine the freshness. ([arch-hypermedia-caching](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-caching)) | ||
| - [x] 22. The hypermedia controls MAY be cached outside the Thing and used for offline processing if caching metadata is available to determine the freshness. ([arch-hypermedia-caching](https://www.w3.org/TR/wot-architecture11/#arch-hypermedia-caching)) |
There was a problem hiding this comment.
We talked about it in the TD call and the TF agrees to A1.
Description of Changes
This PR contains my first attempt at categorizing the TD-related assertions from the architecture document that have been assigned to me via #2126.
Related Issue
#2126