The relationship between content and permalink
The permalink points to the representation of the entry in the context of the publisher's website. Content is the body of what is represented in the entry. A resource that this entry makes reference to (see Related) is what a weblog entry might be referring to. Content is optional in syndicated feeds.
Example: if you write a weblog entry about a an article on the NYTimes, then permalink points to your weblog entry, not the NYTimes article. The NYTimes article is referenced by, or related to, this entry. See Related.
Example: if you have a photolog, the permalink points to your web page with the photo on it, maybe with captions and camera settings, and navigation for the rest of your site. Content is the photo itself and/or a thumbnail of the photo.
Example: if you have an audio blog with series of audio entries on your weblog page, but no seperate pages for each entry, the permalink points, preferrably with an anchor, to your webpage and content is the audio file itself.
Example: if you run an Internet radio station with no "entries" for individual songs or performances, the permalink points to the channel or website and content is the audio or a reference to the audio.
Example: the original RSS definition of <link> was a reference to a resource this entry described. Later, <link> took on a dual role of a reference and a permalink. guid is a unique identifier that may also be a permalink. <description> originally was a brief synopsis or abstract of a story (WellFormedEntry calls "summary") and later took on a dual role of a synopsis or the full content of the entry. content:encoded and xhtml:body share the same definition as <description>, but notably are used more often only when the entire body content is being syndicated. Some use content:encoded or xhtml:body to carry the full body content of an entry and put a synopsis in <description>.
Example: if you run a SideBlog / LinksLog, <link> points to the page where the user can see the SideBlog, preferrably with an anchor to the specific entry. The referred-to article or weblink is referenced by, or related to, this entry. See Related.
[TimothyAppnel] Can/should the linked content also be embedded?
[JoeGregorio] Can the linked content also be embedded? Yes. Should the linked content also be embedded? Maybe. Or maybe just include an excerpt/abbreviation of the content. As an example, a thumbnail could be used as abbreviated content in the case when an image is the linked content.
[JoiIto, RefactorOk] I want to work with media types such as photos, sound and video. There will be API's to access these media types in addition to simple links. (Although I supposed these API's are just URI's...) There is also a great deal of associated metadata. Would like to figure out a good place to discuss this issue.
[Moof, RefactorOk] It looks likely that we'll end up working with media. I, for one, am also after working with photographs, and possibly movies. I don't think EmbeddedContent should be mandatory, can you imagine a feed which has excepts of the latest 20 videos to be put on the site? Links would be more appropriate for that. However, having that option for an internal network, or for thumbnails for a photoblog should remain an option. There is no reason why text should be treated specially.
Should content be optional? If we take the example of RSS1.0 for a moment (I'm not familiar with RSS2.0) there is an <items> tag which lists the items contained in the feed in the order in which they are to be displayed [ICouldBeWrongHere]. I could easily see, for more bulky media types, someone producing an "abbreviated" feed which just lists links to the metadata in question, similar to the <items> sequence, but has no content or metadata after that. An aggregator would then see that a link in the list is new, and fetch that metadata separately, with thumbnails, movie segments, or whatever, and display it seamlessly as far as the user is concerned. This means that previously cached metadata would not have to be downloaded. The "here's a list of entries with their content" approach works for text. I don't think it works for other media.
Also, I think it should be allowed for content to be heterogeneous. I can think of at least one site which normally has text/plain updates, but every so often updates in HTML. Ditto HTML with ocassional photo updates, and so on.
The use of MIME will be important, certainly for media and for the API.
Another point: title and description are not mentioned explicitly here, and a separation for title, description, and maybe even body should be mentioned I think. Both title and description (and/or body) are useful for tools, such as newsreaders, and a standard way of describing them is a must. While they might be optional (Movable Type has a default -though non-mandatory- field for title, while Blogger doesn't) the way to describe them should be standarized, and it will be useful both for output (syndication) and input (API).
[HaroldGilchrist] There will be times when the main context of the entry will not be of type html. The use of "media link" or "content link" needs to be added as we expand to these new media context entries such as audio, images and video. This link is tied directly to the actual media file.
We could also define a "meta link" that ties directly to a xml file that defines the media type file specific information in relation to the content of the entry. ie. audio - file size, duration, sample bits, sample rate, etc.
If permalink remains, it will need to be generic and clearly defined to cover content entries of all types.
[DaveMeehan] Should there be content in and item? Maybe the embedded content should be restricted to text/plain, and any other mime type should be externally linked. This has the advantage of keeping the Echo feed as light as possible, but allows content publishers to provide content suited to different purposes or device types. For example, CNN might have video of an interview, audio of an interview, an HTML transcript and a plain text transcript. The aggregator can choose or offer the user a choice of how to receive the content.