On 16/1/06 3:46 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
>> Thus, in the same sense I might have elsewhere a collection of >> images, I have here a collection of atom categories. > > That doesn¹t even work, because this is invalid: > > <entry> > <!-- ... --> > <content type="application/atom+xml"> > <category .../> > <category .../> > <category .../> > </content> > </entry> No, that isn't one entry in a collection of atom categories, that is one entry in a collection of *bundles* of atom categories. That's as wrong headed as trying to squeeze *three* images into the one atom media entry. If I have three categories in the collection, then they would be in three individual entries. > An atom:content with an XML media type MUST have exactly one > child element, so you can¹t do that. You need to wrap those > categories in something. The manifest choice is atom:entry If I have a collection of atom:categories, the atomic unit is one atom:category. So having a collection where each entry has *one* atom:category in the atom:content element is what I would be trying to do. If I wanted to have a collection of _bundles_ of atom:categories, I'd probably need some foreign element to act as the bundling element (eg. <foo:categories>) > Which just so happens to be a valid root element for > `application/atom+xml`. Of course, you¹re pulling in an entire > train of metadata elements at that point, which will probably be > completely redundant, so whether that is any help I don¹t know. I don't want that train of metadata. I already have an atom:entry with which to carry metadata for that content. (Heh, I could even apply atom:categories to that content, same as any other content ;-) The last niggling concern is with atom-format: although atom:content can contain XML, can that be *any* XML data, or does the spec forbid atom+xml from there? What will the validator do? e.
