Conceptually, it is simpler to think of content as "one thing". Yet, we know well (or just intuitively?) that there are needs for alternate representations. We can spend cycles developing a new model for multiple parts, which will complicate the model overall, but it may be necessary.

An alternative, if you don't mind the pun, is to use MIME Multipart (or its XML equivalent if needs be, physically speaking). This allows the Echo to have one content value, which can also be alternatives (Multipart/Alternative), and can also include a deeper copy of the content (Multipart/Related). Or, it can be a single value, image/jpeg or text/html. In all cases, the content can (should be able to) be embedded or linked.

MIME related:

[HaroldGilchrist, RefactorOk] I agree we should use and support all existing Internet standards. And I like the "one" content value idea using something like MIME Multipart. But not all content cases for ECHO will fit into what is presently defined (nor should the requirement be to make it fit into something existing).

That said, we will need to work as a group to define a living list of "ECHO multipart media types extensions" that are not yet derived in the existing method ( such as MIME Multipart) to support all ECHO content defined uses.

CategoryArchitecture, CategoryModel