Extension mechanism

["Danny Ayers" <danny666@xxxxxxxxxxx>]

Hi folks,

Great to see the list.

One thing about the syntax that concerns me greatly is that there doesn't
yet appear to be a consistent way of interpreting material from other
namespaces. I believe this to be a make or break issue for interop.

Such a mechanism is also lacking from RSS 2.0, which relies on extension
modules to define how they are to be used. This approach is IMHO totally
inadequate, the main reason be that it is likely to lead to inconsistency in
the way external data has to be handled by an Atom processor. This will make
coding harder.

The issue was however thoroughly covered in RSS 1.0 thanks to RDF/XML. I
doubt very much that the richness of the full RDF graph is needed inside
Atom, but I think it will be desirable to be able to extend into or attach a
full graph if required. In fact, another justification for a sound extension
mechanism is to be able to interoperate with RSS 1.0 and other RDF data.

It has been suggested that "ignore anything you don't recognise" might be a
suitable mechanism, but I believe this has two major flaws : the parts that
aren't recognised may alter the meaning of other parts of the feed (e.g. a
Creative Commons license, or a element saying "this is all a joke"), so
their total omission may have side effects; valuable data is being thrown
away (compare the RDF approach).

A start has been made on defining extension modules on the Wiki [1], but as
yet there doesn't seem to be anything substantial.

I believe that such a mechanism can be defined without any impact on the
work that has been done so far. All I think that is needed in the core is a
means of saying whether an included element from another namespace is
additional content, *or* is additional information about its parent. I've
put a strawman on the Wiki [2], in brief :

1. Any elements outside of the Atom namespace within a <metadata> element
will be interpreted as being about the parent element.

2. Any other elements outside of the Atom namespace will be interpreted as
secondary content associated with their parent element.

The use of a <metadata> element has prior art in SVG [3], where it seems to
work quite well.

Cheers,
Danny.

[1] http://www.intertwingly.net/wiki/pie/ExtensionModule
[2] http://www.intertwingly.net/wiki/pie/SyntaxExtensionMechanism
[3] http://www.w3.org/TR/SVG/metadata.html


----

http://dannyayers.com