Alternative (Re)presentation

An example of this is a WellFormedEntry being rendered in HTML, RSS, OPML, or whatever other formats may exist. It is conceivable that the WellFormedEntry would be required to keep track of all of it's various physical representations and know how to direct folks to each.

Prior art from other domains:


[MarkCidade] I think HTTP ContentNegotiation is relevant to this.

[MarkNottingham] I'm beginning to suspect that we'll end up with a format that serializes multiple alternate representations as content modules; it would be nice if the content modules could optionally replace the content with a URI if you don't want to include it locally.

[JamesSnell] At this point, I'm thinking that this is yet another form of ContentModule, where the value is a link to another location rather than the body of the content itself.

[TimothyAppnel] +1 James.

[BillKearney] I'd favor some sort of mechanism that allowed for programmatic resolving of available alternatives. As in, make it possible to use a common querying mechanism to ask what other formats of an item are available.

[JasonGorman] I would find that very useful, too.

AlternativeRepresentation should be folded into content: [OpenPoll]

Yes: KenMacLeod, AsbjornUlsberg
Mu: TimBray, TimothyAppnel, BillKearney, JeremyGray

[TimBray] Mu explained: This is not something that needs to be defined at the current time; we do not have sufficent consensus, experience, or running code. I suggest amputating this branch of the tree or sticking it in FutureWork.

We could use something similar to (or exactly) MIME Multipart/Alternative as the single content type in content. Discussion on this angle in MultipleContentDiscussion

CategoryModel, CategoryExtension