Content by reference?
[AsbjornUlsberg] What if you want a <description> of the "href", then? <content type="image/jpeg" href="http://www.example.com/fishing.jpeg"><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.
[AsbjornUlsberg] I think we talk about different things. My comment was to wether "href" should be an element or an attribute, and not wether we should have external references at all. If I understand you correctly, extarnal references (or external content -- I can't see the difference) shouldn't be allowed in Echo 1.0. This sounds horrible to me, as we lose extreme amounts of flexibility by not allowing this. Also, it forces people to place images and other stuff base64-encoded and inline, instead of as an external reference which the aggregator (or the user of it) can chose to download or not. I think rather that base64 should be disallowed, so that binary stuff won't get plunged into Echo.
[GeorgBauer] RSS already has some content-by-reference, it's the enclosure element. So I think as we should at least deliver the capabilities of RSS, we really should think about this, too. For example Adam Curry uses this to great extent to deliver an RSS feed of rich media content like movies - which definitely are not usefull as base64 encoded inline content ;). So I say we need content by reference now.
[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 http://www.loc.gov/standards/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.
[AsbjornUlsberg] I agree with you, Chris. The <content> should either contain the content inline, or as an external reference. How the content is reference isn't very important, but I'm leaning towards having it as an element, since then you could also have an <description> of the content you're referring to. Then you will have a <content> element with either an <uri> + <description> or <data> + <description> + <excerpt>.
[ChrisWilper] I think that any kind of "description" metadata should be taken from the entry element itself. In other words, whether content is given by reference or straight inclusion, I think the data model of the entry should be the same.
[HaroldGilchrist, RefactorOk] With "description" do you mean in relation to metadata about the content type or entry content context. An example of content metadata of type video might be: file size, duration, height/width, etc.
[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.
[GeorgBauer] I think this sounds reasonable simple and flexible. It blends nicely with alternative display selections (as you always have the text content - but this should then be restricted to XHTML, because it must be wellformed) for non-capable devices and doesn't extend the main structure too much (me for example quite dislikes the _format_ of the enclosures in RSS, but likes the _concept_ of them).
[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).
This can be done with the Related extension.
[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.
For posting entries, we need base64 encoding (or other standard means);
For synidicating Necho feeds, we use content-by-reference, probably with attributes indicating the URI, type(MIME);
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