Subject: More about Extensions

From: David Powell <[email-masked]>
Date: Tue, 9 Aug 2005 21:50:57 +0100

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

---

From: Robert Sayre <[email-masked]>
Date: Tue, 9 Aug 2005 18:22:14 -0400

On 8/9/05, David Powell <[email-masked]> wrote:
> important...

Sorry, I don't buy this. You're wrong, but the rationale is important. :)

What are we going to do, outlaw strings that happen to look like
relative references? If you want a generic processor to handle your
extension, you've got atom:link, which will work fine. Maybe you want
the relative reference to point at something relative, no matter where
it ends up. I can't think of why anyone would want to do that, but
maybe they will. Relative references are fragile, and people
understand why they break. None of the other pros for this capability
are affected.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Wed, 10 Aug 2005 01:11:38 +0100

Tuesday, August 9, 2005, 11:22:14 PM, Robert Sayre wrote:

> relative references?

No, we just need to warn publishers (and extension authors) that the
base URI of Simple Extension elements is not significant, and that
they must not expect it to be preserved.

We do the same regarding xml:lang already by saying that the element
is not Language Sensitive, which means that the language context is
not significant and that publishers must not expect it to be
preserved.

from Section 2:

> The language context is only significant for elements and attributes
> declared to be "Language-Sensitive" by this specification.

I'd suggest adding something similar to Section 6.4.1, eg:

"The base URI is not significant for Simple Extension elements."

> Relative references are fragile, and people understand why they
> break.

Publishers should expect that relative refs used in atom:link will
work, but publishers should expect that relative refs used in Simple
Extensions will break.

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Tue, 9 Aug 2005 20:30:54 -0400

> work, but publishers should expect that relative refs used in Simple

Disagree. We have no idea what people will do with this, or where they
will be deployed. You're suggesting adding implementation advice,
since the content of a simple extension element is not defined as a
URI reference. By your logic, we have to explicitly clarify that
atom:updated is not subject to xml:base processing. Sorry, I strongly
disagree.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Aug 2005 17:34:44 -0700

> they must not expect it to be preserved.

Either the software understands the foreign markup, in which case it  
might recognize a relative URI, in which case it should apply the  
correct base URI, or it doesn't, in which case everything in the  
foreign markup is just a semantics-free string.

The problem could hypothetically arise when someone extracts  
properties from the foreign markup, stuffs them in a tuple store, and  
then when the software that knows what to do with comes along and  
retrieves it and recognizes the relative URI and can't do much  
because the base URI is lost.

So... IF you know how to handle some particular extension, AND IF you  
expect to handle it when the extension data has been ripped out of  
the feed and stored somewhere without any context, THEN you shouldn't  
use a relative reference.  Alternatively, IF you want to empower  
extensions to process they data they understand, AND IF you want to  
rip that data out of the feed and store it somewhere, THEN it would  
be smart to provide software an interface to retrieve context, such  
as feed-level metadata and the base URI.

Sounds like implementor's-guide material to me.

And, to whoever said relative references are "fragile": Wrong.  When  
you have to move bales of web content around from one place to  
another, and just supposing hypothetically that you have internal  
links, relative references are robust, absolute URIs are fragile.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Tue, 9 Aug 2005 20:46:33 -0400

On 8/9/05, Tim Bray <[email-masked]> wrote:
> links, relative references are robust, absolute URIs are fragile.

And when you have bales of web content that have to be displayed on a
super-wide variety of display technologies, many of which have limited
supported for changing and mixing base URIs (like HTML), relative
references are fragile. This is the kind of situation you run into
with syndication formats, and it should go in the implementation
guide.

Robert Sayre

---

From: James M Snell <[email-masked]>
Date: Tue, 09 Aug 2005 17:56:01 -0700

> Sounds like implementor's-guide material to me.
++++1

- James

---

From: Henry Story <[email-masked]>
Date: Wed, 10 Aug 2005 08:43:29 +0200

Sorry to note the obvious, but does this not sound so much like a  
good reason we should
have engineered atom to *be* RDF? Is this not exactly one of the many  
problems that RDF
sets out to solve?

Henry Story

On 10 Aug 2005, at 02:34, Tim Bray wrote:
> Either the software understands the foreign markup, in which case  
> it might recognize a relative URI, in which case it should apply  
> the correct base URI, or it doesn't, in which case everything in  
> the foreign markup is just a semantics-free string.
>
> properties from the foreign markup, stuffs them in a tuple store,  
> and then when the software that knows what to do with comes along  
> and retrieves it and recognizes the relative URI and can't do much  
> So... IF you know how to handle some particular extension, AND IF  
> you expect to handle it when the extension data has been ripped out  
> of the feed and stored somewhere without any context, THEN you  
> shouldn't use a relative reference.  Alternatively, IF you want to  
> empower extensions to process they data they understand, AND IF you  
> want to rip that data out of the feed and store it somewhere, THEN  
> it would be smart to provide software an interface to retrieve  
> context, such as feed-level metadata and the base URI.
>
> And, to whoever said relative references are "fragile": Wrong.   
> When you have to move bales of web content around from one place to

---

From: David Powell <[email-masked]>
Date: Wed, 10 Aug 2005 09:34:35 +0100

> URI reference.

I want to know whether an implementation is corrupting data if it
discards the base-uri of simple extensions. I think that it is the job
of the spec to tell me this, not the the job of "implementation
advice" to decide this.

> By your logic, we have to explicitly clarify that

Are you saying that we don't need clarification because it is obvious
that simple extensions only contain strings that aren't subject to
base processing?

I think that it is pretty clear, but as Tim disagrees, I think that
this is a good indication that we need clarification.

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Wed, 10 Aug 2005 09:34:37 +0100

> because the base URI is lost.

I expect that many Atom Protocol server implementations will work this
way.

> use a relative reference.

The 1st/2nd "you"s are likely to be a different person from the 3rd
"you". You seem to be saying: "if the consumer knows how to handle
some particular extension [...] then the producer shouldn't use a
relative reference". How does the producer know what the consumer will
do?

(Well of course that is the job of the specification, which is my
point here).

> Alternatively, IF you want to empower extensions to process they
> data they understand, AND IF you want to rip that data out of the
> feed and store it somewhere, THEN it would be smart to provide
> software an interface to retrieve context, such as feed-level
> metadata and the base URI.

It sounds like you disagree with the rationale for Simple vs
Structured extensions in [1]. So can I ask you why you think Atom
defines Simple and Structured Extensions, when according to your
understanding they need to be processed in exactly the seem way
(though simple aren't language sensitive - which seems a bit odd if
you believe that).

I think that the second paragraph of 6.2.1 is pretty clear about what
Simple Extensions mean (the value range of the property is character
data, not character data plus base URI and language context), and that
base URIs would be irrelevant to their processing, but I thought that
it might need some clarification as once people start using them for
URIs there is a risk that people could start using them for relative
refs, given the lack of explanation or rationale for their purpose.

> Sounds like implementor's-guide material to me.

Alternative 1 is not implementable, and alternative 2 suggests
processing that is not compatible with the intended purpose of Simple
Extension elements.

I wasn't entirely convinced that we needed to add this clarification,
but now I am sure that we do.  If there is a belief that
implementations SHOULD preserve the base uri of Simple Extensions then
we need to indicate that this is not true, else Simple Extensions
will be broken from the start.

[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html

-- 
Dave

---

From: "Roger B." <[email-masked]>
Date: Wed, 10 Aug 2005 17:12:30 -0500

Dave: I think I see what you're getting at... correct me if I'm wrong.

So I decide that my aggregator is going to look for unknown Simple
Extensions in Atom feeds and display them as a table of name/value
pairs at the bottom of every entry. And during the display process,
I'm going to run a regex over the values and linkify any URLs I find.

When someone's relative references just sit there as plain text and I
get a complaint, who's to blame?

(1) Me, for trying to provide generic support for unknown extensions?
(2) The publisher, for failing to consider non-specific or limited
support of the extension?
(3) The complaining user, for expecting too much?

If it's (3), then I agree with Tim... the spec says what it says, and
that's fine. Otherwise, there may be a legitimate problem here.

--
Roger Benningfield

---

From: Robert Sayre <[email-masked]>
Date: Wed, 10 Aug 2005 18:33:46 -0400

> this is a good indication that we need clarification.

I think it's good indication that you've argued with everyone, no
matter what they say. I'm strongly opposed to adding anything like
you're suggesting. Tim and I agree that the current text is
sufficient. There's a word for that.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Thu, 11 Aug 2005 09:04:54 +0100

> get a complaint, who's to blame?

Another example is:

An AtomPP client publishes entries to an AtomPP server.  The server
stores the entries in a CMS.  The CMS publishes the entries as an Atom
feed.  The CMS shouldn't have to preserve the value and base URI for
each extension attribute.  Simple Extensions were designed with this
sort of scenario in mind.

> that's fine. Otherwise, there may be a legitimate problem here.

Well I think that it can't be (1). We wouldn't have wrote section 6.4.1
and 6.4.2, if we didn't want to support this.

It shouldn't be (3) either. If the publisher puts something into an
Atom document, it shouldn't be ambiguous whether it is a URIRef or
not, even for extensions.  This is what I mean by extensions being
part of the Atom model.

We wouldn't have banned Simple Extensions from containing language
sensitive text, if we were requiring implementations to preserve each
of their base URIs.

This paragraph explains that, but obviously not well enough:

> The element can be interpreted as a simple property (or name/value
> pair) of the parent element that encloses it. The pair consisting of
> the namespace-URI of the element and the local name of the element
> can be interpreted as the name of the property. The character data
> content of the element can be interpreted as the value of the
> property. If the element is empty, then the property value can be
> interpreted as an empty string.

I'm requesting that some clarification be added specific to relative
refs.

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Thu, 11 Aug 2005 09:00:00 +0100

> sufficient. There's a word for that.

I might have misinterpreted your comment, but I'm arguing with Tim for
saying that SEE's CAN contain relative refs and no clarifification is
needed, and with you for saying that SEE's CANNOT contain relative
refs and no clarification is needed.  There's a word for that :)

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Thu, 11 Aug 2005 10:05:34 +0100

> refs and no clarification is needed.  There's a word for that :)

I oversimplified that.  What I really meant is not that rel refs are banned, but
that publishers should not expect rel refs to be processed differently than
strings.

The value of a Simple Extension is a string.  It is the job of an unextended
Atom implementation to transfer those strings.

Extensions can encode what they like in those strings, and if the extension is
supported by the receiver, then it can be decoded.  A publisher can put
numbers, dates, URIs, or escaped XML in one of these string; they can even put
relative refs in there, but they must only expect the string to be preserved,
not the context of the surrounding XML.  SEE's exist so that simple properties
can be transfered without requiring that the CMS store an Infoset equivalent.

--
Dave