Subject: Labeling of atom:content elements

From: "Jon Davis" <[email-masked]>
Date: Sat, 2 Oct 2004 01:39:05 -0700

I know this was debated but it seems clear that this is still broken and
unaddressed. If atom:content is to be of more use than formatting and
language options, then the atom:content elements that are NOT themselves of
type "multipart/alternate" (i.e. the children of the "multipart/alternate"
element) MUST be named with a text string as an attribute, or else they are
useless. This is not to be construed to be a distinct ID, but as a
human-readable filename where duplicates are allowed.
 
Imagine Atom being used in a similar method as an e-mail document. Atom
supports MIME-typed attachments, but does not support named MIME-typed
attachments. It doesn't make sense. An e-mail document is perceived as an
entry in much the same way as an Atom entry is viewed, but e-mail
attachments (Word documents, PDF documents, etc.) can be saved to the hard
drive without trouble. Same with NNTP messages; Outlook Express know to hide
the HTML/text formatting-alternative versions from the attachments list
while displaying everything else. You guys know this. Why on EARTH does the
draft still require implementors to depend entirely on indexing and user
intervention for content naming?
 
Jon

---

From: Antone Roundy <[email-masked]>
Date: Sat, 2 Oct 2004 09:34:17 -0600

On Saturday, October 2, 2004, at 02:39  AM, Jon Davis wrote:
> I know this was debated but it seems clear that this is still broken 
> and unaddressed. If atom:content is to be of more use than formatting 
> and language options, then the atom:content elements that are NOT 
> themselves of type "multipart/alternate" (i.e. the children of the 
> "multipart/alternate" element) MUST be named with a text string as an 
> attribute, or else they are useless. This is not to be construed to be 
> a distinct ID, but as a human-readable filename where duplicates are 
> allowed.
>  
> Imagine Atom being used in a similar method as an e-mail document. 
> Atom supports MIME-typed attachments, but does not support named 
> MIME-typed attachments. It doesn't make sense. An e-mail document is 
> perceived as an entry in much the same way as an Atom entry is viewed, 
> but e-mail attachments (Word documents, PDF documents, etc.) can be 
> saved to the hard drive without trouble. Same with NNTP messages; 
> Outlook Express know to hide the HTML/text formatting-alternative 
> versions from the attachments list while displaying everything else. 
> You guys know this. Why on EARTH does the draft still require 
> implementors to depend entirely on indexing and user intervention for 
> content naming?
>
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList is a list of the 
proposals that have been made thus far, and indicates those that are 
currently under discussion, one of which is PaceNukeMultipart[1].  If 
I'm not mistaken, that proposal has strong support and little or no 
opposition, so the whole discussion of the current 
multipart/alternative mechanism is about to become moot.  I'm also of 
the impression that there is support for disallowing more than one 
content element, as evidenced by the proposed change to section 5.10 in 
PaceReformedContent3[2], which is receiving broad support.  Of course, 
it may be that after that proposal is accepted (assuming it is), there 
will be efforts to resurrect some sort of multiple content.  I for one 
don't feel particularly strongly either way about whether to allow 
multiple language and format alternatives.  I can imagine it being 
useful on the one hand, and I can imagine it adding complexity that 
very few people use on the other.

But getting to what you're discussing--attachments--I think it would be 
better to have an element to be used specifically for attachments than 
to put attachments into multiple content elements and add attributes to 
identify the primary content and to name the attachments.  There's also 
the question of whether attachments should be linked to or included 
inline.  I think there are reasons for doing them either way under 
different circumstances, and even for distinguishing between secondary 
content that the publisher wants to suggest be rendered alongside the 
primary content, and secondary content that the publisher simply wants 
to link to (the link element being the appropriate mechanism for the 
latter).  A few relevant proposals to give you an idea of what has been 
discussed (but not entirely resolved) already include 
PaceLinkPurpose[3], PaceExtensionNamespace[4] (the section on "Embed" 
constructs--not that I think this specific proposal will be adopted, 
nor as the author am I likely to support it anymore, though I'd still 
like to come up with a solution for the issue it addresses), and some 
that have been closed: PaceGraphicElement[5], PaceNonEntryResources[6] 
and PaceObjectModule[7].

Antone

[1] http://www.intertwingly.net/wiki/pie/PaceNukeMultipart
[2] http://www.intertwingly.net/wiki/pie/PaceReformedContent3
[3] http://www.intertwingly.net/wiki/pie/PaceLinkPurpose
[4] http://www.intertwingly.net/wiki/pie/PaceExtensionNamespace
[5] http://www.intertwingly.net/wiki/pie/PaceGraphicElement
[6] http://www.intertwingly.net/wiki/pie/PaceNonEntryResources
[7] http://www.intertwingly.net/wiki/pie/PaceObjectModule