Subject: Default atom:content item

From: "Jon Davis" <[email-masked]>
Date: Fri, 1 Oct 2004 19:54:31 -0700

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

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 1 Oct 2004 20:25:30 -0700 (PDT)

> representation of the item.

That makes sense but the Atom 0.3 spec does not
specify a mechanism for doing this. Considering that
the Atom 0.3 spec was just intended to be a rough
draft it is unsurprising that there are holes in the
spec such as these. 

> presumes a single content entry.

I'm confused by your use of the phrase "backwards
compatible". I assume you mean "compatible" not so? 

Also I wonder why you are planning on making your
implementation create made up attributes for the
atom:content element which are not in the spec nor
have they been specified in the IETF drafts of the
Atom spec. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

---

From: "Jon Davis" <[email-masked]>
Date: Fri, 1 Oct 2004 20:45:51 -0700

> I'm confused by your use of the phrase "backwards compatible". I 
> assume you mean "compatible" not so?

Yes, compatible, not backwards compatible.

> Also I wonder why you are planning on making your implementation 
> create made up attributes for the atom:content element which are not 
> in the spec nor have they been specified in the IETF drafts of the 
> Atom spec.

As you said, "Atom 0.3 [draft] spec does not specify a mechanism for doing
this" because "the Atom 0.3 spec was just intended to be a rough draft it is
unsurprising that there are holes in the spec". If the draft spec has since
been modified, I would greatly appreciate the education of the proper
mechanism.

Until then, implementors are free to extend specs, as there is nothing in
the atom:content specification that indicates that there must be no other
attributes in this element. This is a good thing, too; in XML
implementations it is generally a bad idea to disallow custom attributes to
XML nodes unless there is a very good reason, simply because of the
extensibility, or the 'X', of XML.

I shared about my implementation because the spec proved insufficient in
this area. I posted to this group to allow discussion of this mechanism; if
anyone knows of a better idea for this mechanism, please share.

Discussing the adaptation of the draft Atom specification, including the 0.3
draft, is the purpose of this list, is it not?
Thanks,
Jon

-----Original Message-----
From: Dare Obasanjo [mailto:[email-masked]]
Sent: Friday, October 01, 2004 8:26 PM
To: Jon Davis; [email-masked]
Subject: Re: Default atom:content item

--- Jon Davis <[email-masked]> wrote:
>
> 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.

That makes sense but the Atom 0.3 spec does not specify a mechanism for
doing this. Considering that the Atom 0.3 spec was just intended to be a
rough draft it is unsurprising that there are holes in the spec such as
these. 

> 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.

I'm confused by your use of the phrase "backwards compatible". I assume you
mean "compatible" not so? 

Also I wonder why you are planning on making your implementation create made
up attributes for the atom:content element which are not in the spec nor
have they been specified in the IETF drafts of the Atom spec. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23 I will keep a special cache of
low-tech weapons and train my troops in their use. That way -- even if the
heroes manage to neutralize my power generator and/or render the
standard-issue energy weapons useless -- my troops will not be overrun by a
handful of savages armed with spears and rocks.

---

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

>
>> 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

 

- Jon Davis

---

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

<<

After further thought, as a reader implementer I could care less about the
@mode. If two of the same @type are offered, regardless of @mode, I will be
confused. Change the above from "unique @type / @mode pair" to just "unique
@type".

Jon

  _____  

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

true, 

 
A content defaulting mechanism actually is suggested in the draft:

 

 
Jon

  _____  

 

 
- Jon Davis

---

From: Eric Scheid <[email-masked]>
Date: Sat, 02 Oct 2004 18:13:45 +1000

> confused. Change the above from "unique @type / @mode pair" to just "unique

So you disallow the possibility of a feed containing both a French and an
English variation with the same @type?

    <content xml:lang="fr" type="text/plain"> ... </content>
    <content xml:lang="en" type="text/plain"> ... </content>

there are some institutions which want to, or for that matter are required
to, publish dual language resources.

e.

---

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

>>> 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.
>
> The atom-format spec should not be dictating behaviour of things that 
> consume or produce feeds. It exists to specify the format, and what is 
> legal/error in that format.

I disagree, for the reason I explained at the start. Consider someone using
an Atom implementation producing an Entry with a primary formatting of
XHTML, an ASCII alternative, and an attached Word document that should be
treated as an attachment rather than as the primary Entry content.

There needs to be some identification of content that is associated in
purpose with the actual post (i.e. HTML and ASCII formats of the same
content) and of content that is distinct in purpose from the actual post
(Word document attachment containing ADDITIONAL information, etc.)  In the
current model, anything goes, nothing is labeled, nothing is identified as
the primary content. This is unacceptable. There are ways of resolving this.

- Identify the primary content as "primary content" (i.e. a "primary" or
"default" attribute with a value of true)
- Place content that is NOT to be treated as "primary content" in a separate
"bag" (a separate element, such as an atom:attachments node).
- Specify in the specification that content elements distinct from the
"primary content" (attached files) should not be used, but rather the author
should anticipate that all atom:content elements will be treated as
identical in purpose, varying only in formatting or language.

But it's broken as-is.

Jon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Eric Scheid
Sent: Saturday, October 02, 2004 1:14 AM
To: Atom Syntax
Subject: Re: Default atom:content item

On 2/10/04 3:49 PM, "Jon Davis" <[email-masked]> wrote:

> After further thought, as a reader implementer I could care less about 
> the @mode. If two of the same @type are offered, regardless of @mode, 
> I will be confused. Change the above from "unique @type / @mode pair" 
> to just "unique @type".

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 02 Oct 2004 22:36:52 +0200

On Fri, 1 Oct 2004 19:54:31 -0700, Jon Davis <[email-masked]> wrote:

> attribute

If you're going to implement your own attributes in Atom, you would be  
wise in prefixing them with your own, home-grown namespace. If not, you're  
basically saying «this attribute belongs to Atom», although all attributes  
by default are non-namespaced.

   <content xmlns:jon="http://example.com/jon-davis/atom#default"
     jon:default="true">
     ...
   </content>

would therefore be totally fine. However,

   <content default="true">
     ...
   </content>

is not so okay. Imo, at least.

Also, I would rather recommend you to implement a scoring attribute to be  
able to sort several <content> elements. But this is your implementation,  
so you do what you want. But please try to keep your own elements and  
attributes in your own namespace.

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: "Jon Davis" <[email-masked]>
Date: Sat, 2 Oct 2004 13:43:07 -0700

The discussion of the "default" tag is moot since my awkward discovery of
the purpose of "multipart/alternative".

Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Asbjørn Ulsberg
Sent: Saturday, October 02, 2004 1:37 PM
To: Jon Davis
Cc: Atom-Syntax
Subject: Re: Default atom:content item

> In my implementation, I am going to either watch for a "default"  

If you're going to implement your own attributes in Atom, you would be wise
in prefixing them with your own, home-grown namespace. If not, you're
basically saying «this attribute belongs to Atom», although all attributes
by default are non-namespaced.

   <content default="true">
     ...
   </content>

Also, I would rather recommend you to implement a scoring attribute to be
able to sort several <content> elements. But this is your implementation, so
you do what you want. But please try to keep your own elements and
attributes in your own namespace.