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:
-
RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
-
RFC 2557: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
-
uses standard MIME as wrapper for messages
-
Graham Klyne's XMLization of MIME messages
-
Doesn't implement the body content as XML, no "MIME in XML", but is based on standard MIME as the wrapper for messages
-
aside, has an interesting and useful specification of a generic XML mustUnderstand attribute
-
Jonathan Borden's XML MIME Transformation Protocol (XMTP)
-
implements "MIME in XML" by interpreting the MIME type 'multipart/alternative' as an indicator that multiple Message XML elements will be in the Body element, each with their own content-type, encoding, and value.
[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.