arch-td-consumers-process : Consumers MUST be able to parse and process the TD representation format, which is based on JSON [[!RFC8259]].

[mlagally]

No description provided.

[mlagally]

Other (binary) formats may exist, so I think the part after the comma should be removed.

[benfrancis]

From #625 (comment)...

@egekorkan wrote:

• arch-td-consumers-process : Consumers MUST be able to parse and process the TD representation format, which is based on JSON [[!RFC8259]]. arch-td-consumers-process : Consumers MUST be able to parse and process the TD representation format, which is based on JSON [[!RFC8259]]. #632

This wrong in different levels. First, it is JSON-LD to be specific.

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."
https://w3c.github.io/wot-thing-description/#abstract

"The default representation format for Thing Descriptions is JSON-based as defined by this specification."
https://w3c.github.io/wot-thing-description/#dfn-td-serialization

I assume the term "TD representation format" in this assertion is referring to the TD Representation Format section, which defines a JSON-based representation.

Secondly, a TD does not have to be in JSON.

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."
https://w3c.github.io/wot-thing-description/#dfn-td-serialization

Secondly, processing a TD document is not defined anywhere.

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).

Then, the next assertion arch-other-thing-representations says There 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.

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 links member. I agree that's not all clear from the text though.

Conclusion: ✔️ This assertion could be worded better but overall I agree with it.

---

Suggested action: Remove the assertion from WoT Architecture since it is already covered in WoT Thing Description

[sebastiankb]

I agree with @benfrancis this assertion is already covered by the TD spec in Chapter 6 , mainly with the assertion:

A TD Processor MUST be able to serialize Thing Descriptions into the JSON format [RFC8259] and/or deserialize Thing Descriptions from that format, according to the rules noted in § 6.1 Mapping to JSON Types and § 6.3 Information Model Serialization.

[mlagally]

arch call on 25.11.: remove