RSS extensibility

[Danny Ayers <danny.ayers@xxxxxxxxx>]

In the interests of clarification, consider this pseudo-Atom snippet,
with an extension:

<feed "http://purl.org/atom/ns#
xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/";>

<entry>
   <prism:embargoDate>2005-02-15</prism:embargoDate>
...
</entry>

</feed>

Looking at the PRISM spec (which the namespace qualification identifies) -
[[
embargoDate
Earliest date (potentially including time) the resource may be used
according to the rights agreement, or clause in the rights agreement.
]]

So the human meaning of an 'embargoDate' element is reasonably clear.
The problem is that with RSS 2.0's approach to extensibility, there is
no relationship defined between this element and any part of the feed
data. Ok, it's an embargo date. But the embargo date of what?

On the other hand, following the RSS 1.0 approach to extensibility,
the markup would be interpreted as RDF/XML, which assigns a role for
the different parts of the XML structure. The pseudo-Atom is making
the statement:

_:entry prism:embargoDate "2005-02-15" .

The embargoDate is unambiguously a property of the entry. In the RSS
1.0 case this is defined in the RDF model.

IMHO Atom would benefit from a similar disambiguation mechanism. 

As Henry has suggested this could be through RDF, mapping directly
between the Atom syntax and an RDF representation. This does seem the
easiest way of giving Atom such a mechanism without using RDF/XML. But
an Atom-specific mechanism could relatively easily be defined. The use
of URIs for entries is a good start, but other structural hooks (which
could make sense of the example above) could be added without any
disruption of the core spec as it stands (aside from constraining how
and where such extensions should appear).

This general idea has been the subject of several proposals, including
Sean Palmer's ExtensibilityFramework early on and the more recent
properties-based approach (sorry, not got links, the Wiki is giving me
500s).

I believe the basic extensibility mechanism should be part of the core
spec, though any mapping to RDF might be provided as 'informative'.

Cheers,
Danny.

-- 

http://dannyayers.com