I still believe that relative URIs shouldn't exist in Simple Extension
constructs [1]. I think that the lack of rationale for their being 2-3
classes of extension construct is proving to be harmful.
Prior to the introduction of Section 6, Atom pretty much said you can
include any foreign markup anywhere. I thought that this conflicted
with the claim made by the charter that:
> Atom consists of:
> * A conceptual model of a resource
> * A concrete syntax for this model
I thought that the model should be separable from the syntax, so that
people can use databases and RDF stores as their back-ends rather than
just XML files. And I thought that it was important that extensions
should be part of that model, rather than only be representable in the
syntax, else extensions would be poor-cousins of the core elements.
Restricting Atom extensions to only being simple string name/value
parameters would ensure that they were represented in the model, but
it would have been too limiting.
So the two classes of Extension construct, Simple and Structured, are
a compromise between constraints and flexibility.
The pros and cons of each class are:
Simple Extension constructs:
----------------------------
+ simple string name/value properties of the feed/entry/person. Easy
to implement generically end-to-end in servers/clients so that
extensions can be deployed generically without requiring "boil the
ocean" acceptance.
+ property semantics as described by section 6.4.1.
+ publishing clients could provide an extension editor, where
metadata fields could be added to the clients form, given a
namespace URI and element name.
+ extensions don't need to be defined specifically for Atom. RDF
Vocabularies, RSS extensions, DC, and PRISM already define
properties that are compatible with Atom Simple Extensions.
+ simple, useful mapping to RDF
- can't represent language sensitive text. This decision was made
because very few RSS extensions contain language sensitive text,
(they tend to contain dates, numbers, tokens, URIs etc - when
language-sensitive text is required Structured Extensions should
be used). Also, the barrier for implementations such as custom
property tables, CRMs, and WebDAV implementations would be high.
- can't represent relative URI references, because they are defined
to be strings only, and generic implementations can't know what is
or isn't a URI reference.
Structured Extension constructs:
--------------------------------
+ Can support (almost) arbitrary XML.
- no pre-defined semantics.
+ no pre-defined semantics.
- clumsy generic mapping to RDF (by preserving the XML blob), though
with extension specific knowledge a better mapping could be used.
+ Publishing servers can generically support them by preserving the
blob of XML.
- Publishing clients can't easily generically support them, as the UI
to edit a chunk of arbitrary XML wouldn't be very user-friendly.
- require at least a mandatory attribute or child in order to exist.
Namespaced attributes & atom:link children
------------------------------------------
- Not part of the Atom model - only representable by the syntax.
- Not really practical to support generically; require
"boil the ocean" adoption.
- Really not something I'm keen on as evidenced by this biased
assessment... Are they really allowed for things other than
future versions of Atom?
+ ...OK, they let you add annotations to elements in a way that
would be difficult to address without an RDF style graph-based
format.
Does that sound about right?
So, can we agree that relative URIRefs aren't allowed in Simple
Extension constructs and add a clarification, else their
implementation won't satisfy the rationale for their design.
If I'm wrong, and the rationale behind Simple Extensions isn't
important, then can someone explain why there are two classes of
extension?
[1] http://www.imc.org/atom-syntax/mail-archive/msg16598.html
--
Dave
