Re: meta-issue: arbitrary relationships required?

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

Danny Ayers wrote:

> The displays are based on a interpretation of the data based on the
> semantics encoded in RDF/XML, specifically how a relationship defined
> in an external namespace is associated between a resource in the RSS
> feed and other data/resources. Atom has no such mechanism. 

Oh, ok. You want a place to put properties. That makes sense. Here is my 
proposal:

1.) Properties of atom:entry are child elements of atom:entry
2.) Properties of atom:feed go in atom:head
3.) There is no other place to put extension elements in Atom 1.0

Note that these extensions can be arbitrarily complex (you can even use 
RDF :).

Basically, this means none of the Atom-defined "Common Atom Constructs" 
are extensible, although atom:content has a "blob" property.

Off-the-top-of-my-head methods for dealing with existing "Common Atom 
Constructs":

1.) Content Construct
    You have a "blob". Use it if you have "special" content. A prop
    on atom:entry would probably do otherwise.

2.) Person Construct
    "But I want to put FOAF in!" No, you want to relate FOAF
    information to this entry AND a person. If you have general
    person information, it would be bad to boxcar lots of personal info
    in an entry. If it relates to the entry, it can be a prop of entry.
    If you need to relate extension data to the Person Construct, that
    construct provides a handy URI. Refer to it.

3.) Date Construct
    Don't extend this. Add a new kind of date.

4.) Identity Constructs
    Don't extend this.

5.) Text Constructs (coming soon to a spec near you!)
    Don't extend this.

6.) Link Constructs
    "But I want an extra attribute!" No, you want to enclose the Link
    Construct in an extension element.

> <rambling-opinion>
> There seems to be a tendency around these parts to take a very narrow
> view of what a tool that uses syndication formats should be like...

No, there is a very narrow view of the type of information that is 
useful in this format, especially in core. General-purpose assertions 
are not demonstrably useful in this space, but taking steps to make sure 
they work seems reasonable.

Robert Sayre