RE: A question regarding multiple content

["Jeremy Gray" <jeremy@xxxxxxxxxxxxx>]

> It may very well be the case that for syndication, a single
> content is the right answer.  However, it might also be the
> case the multiple content in one form or another is required
> by an API.  Either for atomicity (no pun intended).  Or
> simply because the server will assign the URLs of the various
> pieces.
>
> Until we have more experience with the API (read: large scale
> implementations), I would not like to close off this option.
> Nor would I like to prematurely lock down the syndication
> format opening up the possibiity of inconsistencies with the
> API.
>
> All that being said, if it turns out the multiple content is
> not needed by either the API nor the syndication format, I'm
> OK with that.

While I too see potential usages for multiple content (i.e. in a CMS which
wishes to support alternate content and persists feed and entry data in the
native XML form and then serves up the appropriate content type to clients
via a selection of feed versions which provide the various types of content
and/or through provision of references to alternate content which can be
retrieved on demand), but...

Not to put too fine a point on it, there are still alarm bells going off in
my head because (as I've already said):
1. The above assumed/intended future use for multiple content isn't
presented clearly enough and/or reflected in
2. A poll whose results say no to multiple content.

If one or more members of the wiki community want to re-present the issues
and fire up another poll, I'd be there in 100% support of the effort, but
until that happens the current state of the multiple content issue just
smacks of side discussions and unilateral actions which raise concern
regarding the community's true involvement in and effect on the wiki, the
process, the project, and the resulting standard. Sorry, but there really
isn't any other way to put it.

Jeremy Gray