-
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
Reconsider the interaction between Thing::base, Form and how the protocol is signaled #1834
Comments
Is related to #803 |
So the linked issue is correct (which also links to #1248). In TD 2.0, we want to introduce a top level term to group such protocol related information. Regarding other points mentioned:
This would help with identifying the protocol. I do not think that a default would be very needed here though.
We need to look into possible issues with this. https://w3c.github.io/wot-binding-templates/bindings/protocols/coap/index.html#observing-resources would not translate well. Also, |
"properties": {
"status": {
"type": "string",
"readOnly": true,
"forms": [{
"cov:method": "GET",
"href": "//[2001:DB8::1]/status",
"contentType": "text/plain;charset=utf-8",
"protocol": "coap+observe",
"op": ["observeproperty"]
}]
}
} With my additional proposal about "properties": {
"status": {
"type": "string",
"readOnly": true,
"forms": [{
"verb": "cov:GET",
"href": "//[2001:DB8::1]/status",
"contentType": "text/plain;charset=utf-8",
"protocol": "coap+observe",
"op": "observeproperty"
}]
}
}
Our |
I think the problem has many different faces (as suggested by the many issues linked in #1248). There is also some loose dependency on #968. My feeling is that if we would rethink the subscribe/observe operations as connections and have this concept of connection as a first-class entity then we could also have a global section where to describe those objects. Anyhow, we should start from somewhere about the concrete proposal here:
I still have to read the final status of the profile document but I would think that this rule applies only if the profile is active for a particular TD, so this is not something for the TD document. Unless we want to go ahead with the idea of profiles as "defaults" protocol bindings configurations.
These points are conservative, which is something that I like.
I definitely agree with this, we need something that tight together the allowed subprotocols, but maybe this is something that can be only solved at the spec level? 🤔 |
I agree it's a bit awkward that there's a single The idea of resolving a URI against a base URI is also well established and standardised and probably shouldn't be re-defined within WoT. Note that HTML also has the restriction of a single I would be cautious about splitting bits of information out of URIs into JSON, whilst also inventing a new way to serialise other information (protocol + subprotocol). I agree the @lu-zero I'm curious what use case led you to discover this problem? Were you writing a Thing Description which uses multiple protocols, and if so which protocols were they? Was it HTTP and CoAP, or some other protocol which doesn't have a formal URI scheme? As @relu91 pointed out this is a multi-faceted issue which also touches on the issue of metadata redundancy, and describing persistent connections for stateful protocols (which I personally think is a separate problem to the one the |
My proposal is to still use the standardised urls, just restricting what you can put in them so we can use relative urls in more occasions.
All still applies, just the information provided by the
Just the general mechanism felt less then straightforward since you basically have to get the information of having the |
Also see w3c/wot-binding-templates#176 We will hold a discussion about this in one of the upcoming TD calls. |
Once a Thing is providing Forms with multiple protocols the
Thing::base
is less useful.I'd suggest to consider
Thing::protocol
defaulting to https. (profile overrides)Thing::base
to be//{host}[":" {port}]["/" {path}]
Form::protocol
to deliver the information on the protocol used, and potentially dropsubprotocol
by usingscheme+subscheme
if we feel we have too many fields.Link::protocol
.Form::href
andLink::href
similarly to base + allowing relative paths and such.The text was updated successfully, but these errors were encountered: