Subject: RE: Default atom:content item

From: "Jon Davis" <[email-masked]>
Date: Fri, 1 Oct 2004 22:16:52 -0700

The "third alternative" is far more limiting than the "second alternative",
as it would disallow distinctive attachments of the same type. Ignore it.
 
Jon

  _____  

From: Jon Davis [mailto:[email-masked]] 
Sent: Friday, October 01, 2004 10:11 PM
To: [email-masked]'
Subject: RE: Default atom:content item

>
>> if an atom:entry element can contain more than one child atom:content 
>> nodes (/feed/entry/content++), one of those content elements should 
>> be marked as a "default" or "master" item, which would normally the 
>> XHTML representation of the item.
>> I am going to either watch for a "default" attribute with a value of
true, 
>> or if that isn't found I will use the first item in the list.

> I am implementing with the default attribute as described in the original 
> post of this thread until this group comes up with a better mechanism.

(While implementing I have noticed that the Content construct has two
variants: one in which Content construct child elements ARE allowed, and one
in which Content construct child elements are explicitly DISALLOWED. For
purposes of discussion, I would like to refer to the latter variant as a
Subcontent construct.)
 
A content defaulting mechanism actually is suggested in the draft:
 
Consumers SHOULD look at all
   alternative content elements and determine which one is most
   suitable, based on which @type and @mode the consumer supports, and
   preferences specified by the end user (if any).
<<
 
However, there is nothing in the specification that indicates that there
should only be one atom:content of a particular @type / @mode.
 
That said, the file type based mechanism is acceptable as an alternative to
a "default" attribute if two new rules are added to the entry element:
 
1. The atom:entry MAY contain more than one atom:content elements IF each
atom:content element has a unique @type / @mode pair.
2. Readers SHOULD NOT refer to any individual atom:content child element of
an atom:content element marked as "multipart/alternative" as the the primary
content of the entry. Readers SHOULD instead determine the primary content
of the entry from the hierarchy of child elements of atom:entry.
 
As a third alternative, apply #1 above but apply it to atom:content children
of atom:content (Subcontent constructs), and instead of #2, remove from the
spec the allowance of multiple atom:content elements as children of
atom:entry and require all instances of multiple atom:content elements to be
under the "multipart/alternative"-typed atom:content element of atom:entry.
 
Jon

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jon Davis
Sent: Friday, October 01, 2004 7:55 PM
To: [email-masked]
Subject: Default atom:content item

I'm new on this list (since months ago), so perhaps this was discussed
before.
 
Looking at v0.3, I see that an atom:entry element may contain more than one
atom:content element. A content element in an entry element can also contain
one or more content elements (/feed/entry/content/content++). I like this,
as it allows for attachments and such. 
 
But if an atom:entry element can contain more than one child atom:content
nodes (/feed/entry/content++), one of those content elements should be
marked as a "default" or "master" item, which would normally the XHTML
representation of the item.
 
In my implementation, I am going to either watch for a "default" attribute
with a value of true, or if that isn't found I will use the first item in
the list. This will allow my implementation to be "backwards compatible"
with those flawed implementations out there that I've found that DO NOT
recognize that more than one atom:content element can be used, as well as
give me and users of my implementation to have a fallback mechanism that
presumes a single content entry.
 
- Jon Davis