Assertion review #625
Comments
|
After thinking a bit about it, nearly all these assertions are about TDs in the end, like how should an op look like, how a TD should be processed etc. They should be in the TD spec in the first place. |
|
There are some assertions that already defined by the TD (e.g., about the usage of content types). I would support that that the list above is removed by the architecture document. It will improve the readability and consistency. |
There's a big discussion that went into DID and other topics. However how can we be able to identify if two TDs refer to the same thing, if we don't have canonicalisation? |
I think that canonicalization is another topic, this assertion is about the |
|
Edit: Now that each assertion has its own issue I've copied my comments into each issue and suggested action for each. @egekorkan wrote:
Actually that's not correct. The default serialisation of a Thing Description is JSON. It can be parsed as JSON-LD but that is optional. This is mentioned in several places in the Thing Description specification, e.g. "Thing Descriptions, by default, are encoded in a JSON format that also allows JSON-LD processing." "The default representation format for Thing Descriptions is JSON-based as defined by this specification." I assume the term "TD representation format" in this assertion is referring to the TD Representation Format section, which defines a JSON-based representation.
That is correct, JSON is only the default. "A TD Serialization follows a given representation format, identified by a media type when exchanged over the network. The default representation format for Thing Descriptions is JSON-based as defined by this specification."
I agree this isn't well defined, and it probably should be. I've proposed this as a deliverable for the next charter period. However, the term "TD Processor" is defined (https://w3c.github.io/wot-thing-description/#dfn-td-processor).
My take on this is that "another representation of a Thing" and "another serialisation of a Thing Description" are not the same thing. There could be an XML serialisation of a Thing Description, but there could also be an HTML page which provides a user interface for Thing, which isn't a Thing Description and both could even share the same URL (using content negotiation). I would assume that Consumers are only expected to parse a Thing Description (and only required to support the default JSON serialisation of a Thing Description), but a Thing Description could link to an HTML representation using an alternate link relation in the Conclusion: ✔️ This assertion could be worded better but overall I agree with it.
I personally don't really agree with this assertion because in my opinion, as far as a WoT Consumer is concerned, two different Thing Descriptions hosted at two different URLs for the same physical device should be treated as two separate Web Things. However, the Thing Description specification does define an I do think the term "correlation" in this assertion is a bit ambiguous. Conclusion: ❌ I don't really agree with this assertion, but let's continue the discussion.
It is certainly possible for a single software application to act as both a WoT Consumer and a WoT Producer (actually WebThings Gateway does this), but I agree the idea of direct Thing to Thing interactions is purely theoretical and I've never really been convinced by that use case. Conclusion: ❌ I think this could safely be removed.
I have no idea what this means either. If I had to guess I'd say it means that the configuration of a consumer could be exposed as properties in a Thing Description so that another Consumer can change its properties. If so then yes that's technically possible but probably not worth mentioning. Conclusion: ❌ I don't exactly disagree, but it probably doesn't warrant a mention.
Conclusion: ❌ I wouldn't mind if this was true, but it clearly isn't true because there's a
As far as I can see there's no mention of this in the Thing Description specification, which just lists the literal values in all lower case. It would be simpler if they had to be lower case Conclusion: ❌ I don't have a strong opinion, but requiring lower case would be simpler.
As you point out in #619, this directly contradicts the Thing Description specification. Conclusion: ❌ This is a contradiction which should be removed.
I don't really understand what this means, but I'd guess it isn't really enforceable. Also, the previous assertion: "Protocol Bindings MUST be serialized as hypermedia controls to be self-descriptive on how to activate the Interaction Affordance." is arguably now contradicted by the WoT Profile specification, which defines details of a protocol binding which do not have to be self-described by a Thing. Conclusion: ❌ This should probably be removed.
I strongly agree with this assertion, but let's continue the discussion in w3c/wot-binding-templates#137. Conclusion: ✔️ I strongly agree with this assertion.
This does kind of make sense, since otherwise how can a protocol binding be described in a form? Does MQTT really have "methods" though, or is that just an HTTP/CoAP thing? I think what this is getting at is that it has to be possible to create a vocabulary to describe the protocol in a Protocol Binding Template. Conclusion: ✔️ I don't have a strong opinion, but this kind of makes sense. I dread to think what other gems are hiding in the WoT Architecture specification which people who are very familiar with the other normative specifications are completely oblivious to. This is precisely the reason that Mozilla made a formal objection to the Architecture specification becoming a W3C Recommendation in the first place. Their feedback at the time was that it should just be an informative note, and that normative assertions should be restricted to the Thing Description specification so that everything is in one place. I still stand by that position and suggest that all normative assertions that the group agrees should be kept are moved to the Thing Description specification to avoid any further misunderstandings. As the WoT specifications multiply in number and cross-dependencies are created, it's getting harder and harder for any one person to understand the whole set of normative requirements. As I've said before, in my ideal world there would only be two specifications:
If we can't do that then hopefully we can at least reduce the number of normative specifications by one, by making WoT Architecture 1.1 an informative introductory note instead of a standards-track normative specification. |
|
To simplify the discussion of these individual issues, I have created a dedicated issue for each of those. |
|
Arch call on 16.12.: |
|
Please see the comments in PR #768 that I just created. I also agree with Ben that the arch-id-correlation assertion should be removed, and in the PR description I also brain-dumped some comments on the discussion in issue #190 in Discovery, but at this point I think we need to move on and removing the assertion at least avoids one source of logical conflicts. In my PR I did massage the text immediately before the assertion to remove the implication that an Intermediary is not a Thing; IMO it is a kind of Thing, and in fact an example of a Virtual Thing. |
Given that #624 has landed, it shed into what are the important parts of this specification, i.e. the assertions. I have some points to review that I am putting in an issue since these assertions exist without that PR as well.
arch-td-consumers-process: Consumers MUST be able to parse and process the TD representation format, which is based on JSON [[!RFC8259]]. #632This wrong in different levels. First, it is JSON-LD to be specific. Secondly, a TD does not have to be in JSON. Secondly, processing a TD document is not defined anywhere. I also do not know what it exactly means. Then, the next assertion
arch-other-thing-representationssaysThere MAY be other representations of a Thing such as an HTML-based user interface, simply an image of the physical entity, or even non-Web representations in closed systems.. So what should I do as a TD parser? It says I MUST parse TDs but then says it can be in literally any format.arch-id-correlation: An identifier in the WoT Thing Description MUST allow for the correlation of multiple TDs representing the same original Thing or ultimately unique physical entity. #635This is source of a big discussion at discovery: w3c/wot-discovery#190
arch-thing-bundling: Things MAY be bundled together with a Consumer to enable Thing-to-Thing interaction. #634First time I am hearing this and I have no idea what it means. A consumer can form a mashup of things but this cannot magically create T2T interactions. At least no one has done in the WG/IG before as far as I know. Thankfully only a MAY assertion.
arch-consumer-configuration: The configuration of the Consumer behavior MAY be exposed through the Thing. #636No idea how this happens. By looking at Fig 17, I still do not understand. What is even Consumer behavior, how is it configured and why can it be through a Thing...
arch-property-readable: The state exposed by a Property MUST be retrievable (readable). #633See #412
arch-op-wellknown-compare: Well-known operation types MUST be compared using a case-insensitive comparison. #637Why give such a Consumer implementation detail?
arch-op-extension: The set of predefined operation types MAY be augmented by Extension operation types chosen by applications. #638See #619.
As an extension, all of the following assertion ids are in question now:
arch-op-extension-uri,arch-op-extension-comparison,arch-op-extension-lowercase.arch-hypermedia-origin: The hypermedia controls MUST originate from the authority managing the Thing that is providing the corresponding Interaction Affordance. #641I think that this assertion is not clear. I do not understand what is trying to be achieved by the MUST assertion. Where else can it originate from? Does this mean that I should not tamper a TD? Or a TD should not contain forms of other Things? Is this some sort of a CORS requirement?
arch-uri-scheme: Eligible protocols for W3C WoT MUST have an associated URI scheme [[!RFC3986]] that is registered with IANA (see [[?IANA-URI-SCHEMES]]). #639I am not sure if this is a requirement. Modbus has no IANA registry neither does MQTT.
arch-methods: Eligible protocols for W3C WoT MUST be based on a standard set of methods that are known a prior. #640I think there is something wrong with this assertion. We are talking about methods but the sentence starts with protocols.
The text was updated successfully, but these errors were encountered: