Wednesday, August 10, 2005, 11:12:30 PM, you wrote:
> 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? 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. > (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. 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