RE: Extension mechanism

["Danny Ayers" <danny666@xxxxxxxxxxx>]

> > 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.
>
> This problem has never been solved in the general case that I know of.
> So I really hope that you're wrong on it's make-or-break-ness.  Worth
> taking a whack at, but don't underestimate the difficulty.

(also
>As I've said before, we shouldn't be trying to invent whizzy new
>technology here, we should just be trying for a clean clear
>specification of what's been proven to work.)

I believe there is adequate (working!) prior art to point to something that
will be appropriate for Atom. I reckon the techniques have been proven, it's
just a matter of finding the sweet spot.

RDF/XML guarantees we know *something* about material from other namespaces
through conformity to the RDF model. It's already been decided that the
uber-model approach of using a complete abstract language from which the
syntax is derived (as in RDF) isn't desirable, yet RSS 1.0 shows that this
approach is possible in the context of syndication.

At the other extreme, Sam and others have experimented with directly
inserting namespace-qualified xhtml into RSS feeds with the intention that
it's there for "display as content". This worked. (Though I can't remember
offhand how conflict with other content was handled).

Element-wrapping of metadata to hide it is a technique proven in SVG.

So I think a braindead simple "this is metadata"/"this is content" data
model (expressed in the syntax) for extension material could work. My
suggestion for the syntax almost certainly isn't ideal, but it's maybe a
start.

Cheers,
Danny.