Subject: PaceExtensionNamespace - alternative ideas

From: Antone Roundy <[email-masked]>
Date: Mon, 13 Sep 2004 11:03:17 -0600

A number of ideas are bouncing around in my head...by which I don't 
mean to imply the existence of a lot of empty space :^o  Various 
methods of making <link> and perhaps other elements extensible have 
been proposed:

1) use qnames in @rel to avoid collisions (PaceLinkRelMechanism as it 
now stands)
2) use schemes in @rel to avoid collisions (PaceLinkRelMechanism as it 
used to be--is this an appropriate way to describe that method?)
3) require registration of @rel values to avoid collisions
4) use different element names instead of @rel, and have an attribute 
name that can only be used in elements conforming to some Construct 
definition from the spec (PaceExtensionNamespace).

The recent mention of MIME's prs and vnd subtypes brings an idea to 
mind for making #3 less difficult:

5) require registration of a prefix for @rel values, and specify a 
character that indicates the end of a prefix.  To avoid looking like a 
qname, I'd recommend against ':'.  Perhaps '-' would be good.  Thus, 
you'd end up with things like <link @rel="xyz-foo" ... /> and <link 
@rel="xyz-bar" ... />, where only "xyz" was required to be registered.  
The advantage of this over #1 and #2 is that applications wouldn't have 
to be namespace aware to deal with extension @rel values.  The 
disadvantage (or is it an advantage?) would be a higher barrier to 
entry.

And another new idea that's closest to #4:

6) Define an atom:construct attribute which can be used to mark 
extension elements as conforming to a particular Construct definition 
from the spec.  For example, if someone wants to make a new Link 
Construct, it would NOT use the <link> element, but instead might look 
like this:

    <foo:bar atom:construct="link" href="..." title="..." ... />

This idea is new to me as of today, but I think I might be ready to 
ditch PaceExtensionNamespace in favor of this approach.

I suppose extension authors could make atom:construct optional or 
required in their elements--it's their extension after all.  The 
drawback to including it would be increased feed size, since it would 
presumably appear in every <foo:bar> in the feed.  One approach 
publishers might take is to include atom:construct on lesser known 
extension elements, and drop it later when and if support for the 
extension grows significantly.