-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review of 5.3.4.2.1 Mapping op Values to Data Schemas #1665
Comments
There are quite a bit to answer here :)
The second one. I agree that we are not clear about this in this table but also in general in the spec. I can add this.
I think that we have to find a proper solution to this. A valid point though. Regarding the change to table, it could also be that one does not provide synchronous true or false. I think that output corresponds to response if there is no |
Yes, sorry :) I actually think that despite the fact it's non-normative, this new table is one of the most important parts of the specification because it's basically a guide on how to write declarative protocol bindings. And my takeaway so far is that for non-trivial examples it's very complicated! |
Indeed it gets messy. For TD 2.0, I have some ideas that are result of offline discussions. It might be an idea to include a "new" keyword in the affordance level called We would still have the issue about going further to say that in cases where the payloads different per operation, a new data schema construct needs to be used. Maybe introducing a map of operations to data schemas. |
@egekorkan Apologies for the late review on #1493 after landing, but some issues have recently come up that led me to review this useful new section.
Properties
Does the Thing to Consumer correlation here refer to a response to an
observeproperty
request, or to all the instances of property readings pushed from a Thing to a Consumer after it starts observing the property?subscribeevent
Thing to Consumer correlation below to use thedata
schema of anEventAffordance
for consistency.(Having a mixture of
readOnly
andwriteOnly
members of an object within the same property sounds complicated! It could be problematic for nested objects and arrays.)Actions
Issue w3c/wot-profile#259 re-raised the question about whether the response to an action invocation request can be different to the action's output. One special case here I think may need clarification is that the
output
data schema should only be assumed to map onto the response ofinvokeaction
whensynchronous: true
. An action withsynchronous: false
implies that the response will not contain the output of the action (if any), which may instead be retrieved as the response to aqueryaction
operation.This then raises the question of what the "Thing to Consumer" data schema should be for the response to an asynchronous action. Could it be contained in
additionalResponses
as in other operations?Events
As above with
observeproperty
, does the Thing to Consumer correlation here refer to a response to a subscription request, or to the event payloads themselves?readOnly
/writeOnly
distinction feels like a bit of hack to me, although I see that it's used in Example 71. Would it make more sense for the Thing to Consumer payload to use additionalResponses (since ExpectedResponse lacks a schema member)?If it's the latter, then the Thing the Consumer correlation should surely use the
data
schema from theEventAffordance
.cancellation
member rather thansubscription
?I note that the data schemas of meta operations are still unclear.
Edit:
Following up on this since I see there's an Editor's Note about this but I can't find an issue tracking it.
readallproperties
- data schema defined in section 5.3.1.1 as a map ofPropertyAffordance
data schemasreadmultipleproperties
- data schema defined in section 5.3.1.1 as an array of property nameswriteallproperties
- My interpretation of section 5.3.1.1 would be that this follows the same data schema asreadallproperties
, but this could be more explicitwritemultipleproperties
- Same as withwriteallproperties
but this is one is arguably even more ambiguousobserveallproperties
- Depending on the protocol binding it's possible that this operation doesn't require a data schema. The subscription itself might not contain a payload and the individual property readings may be sent separately and therefore just follow the data schema of the corresponding PropertyAffordance. But these are just assumptions on my part and none of this is made explicit.unobserveallproperties
- Again, probably doesn't require a data schema but this is not made explicit.subscribeallevents
- If asubscribevent
operation has asubscription
data schema, it's not clear what the payload of asubscribeallevents
operation should beunsubscribeallevents
- If anunsubscribe
operation has acancellation
data schema, it's not clear what the payload of aunsubscribeallevents
operation should bequeryallactions
- data schema currently undefined. This could be a map ofqueryaction
responses keyed by the action name. However, given that the table says that data schema forqueryaction
comes fromadditionalResponses
(of which there can be multiple), it may be ambiguous which data schema to use.The text was updated successfully, but these errors were encountered: