Content by reference?

[AsbjornUlsberg] What if you want a <description> of the "href", then? <content type="image/jpeg" href=""><description>Me, fishing</description></content>. I did agree with you until Arve told me about that situation, then I realised that it's best to have the link as an sub-element of <content> instead of as an attribute.

[TimBray] I think content-by-reference gets us into all sorts of problems that we don't have to solve for Echo 1.0. This is explicitly designed to contain things like XHTML that have all sorts of well-debugged machinery for pointing to external resources and describing them and so on, let's let the <content> take care of it.

[JamesSnell] I agree that content-by-reference can be pushed off and revisited post 1.0 if it is deemed necessary.

[ChrisWilper] I'm strongly favor of content by reference as an option, but recommending that if it's XML-based, to inline it. What sorts of problems are you wary of, Tim and James? Examples please? I work with a format called [METS] that takes care of this kind of thing just fine. It seems to buy a lot of flexibility for little cost to me. I think including a href in a chunk of XHTML instead is kludgy. It has different meaning than pointing to the content straight from the content element.

[LachlanCannon] The model that makes sense to me is having <content type="whatever" [href="whatever"]>Text</content>. That is, an optional href, if it's not present then the contents of the element are the content If it is present, then the resource it points to is the content, and the contents of the content element (ugh) are a fallback for UAs which are unable to fetch or display the specified href.

[JeremyGray] My vote would be for content by reference via an extension module added post-1.0. At that time, instances could take the form of a 1.0 entry without content (assuming content is optional in 1.0) + an extension element pointing compliant aggregators to the relevant content via a yet-to-be-discussed mechanism (presumably HTTP).

[ZhangYining] I think there are two issues here, posting a new entry with content of type other than plain text, and syndicating a feed which has entries with content of type other than plain text.

  1. For posting entries, we need base64 encoding (or other standard means);

  2. For synidicating Necho feeds, we use content-by-reference, probably with attributes indicating the URI, type(MIME);

  3. For both 1, 2, we could use optional (optional for feed/entry provider) metadata to indicate the type-specific attributes, for example size, hight, etc.


[AsbjornUlsberg] If you want to specify one or more images for an entry, the best way to do this imho, is to nest <entry>'s, with content type and "permalink" set. This goes for threaded <entry>'s as well, in discussions and such. Allowing the <entry> element to contain another <entry> element, gives a lot of room for rich entries without doing a lot of work in the specification. Once the <entry> type is defined, we have it.

[JamesSnell] I disagree. Take email as an example. If I want to include multiple images in a single note,

[JeremyGray] -1 to sub-entries, for reasons already covered on pages related to comments, threading, etc. For discussions regarding images, there is enough slippery-slope feature creep happening over on the content page to satisfy anyone's hunger for over-design :)

Category Metadata, CategoryModel