On 8/16/05, Henry Story <[EMAIL PROTECTED]> wrote: > > > On 16 Aug 2005, at 21:00, Mark Nottingham wrote: > > > > I very much disagree; relative references should be allowable in > > simple extensions, and in fact the rationale that Tim gives is the > > reasoning I assumed regarding Atom extensions; if I had known that > > the division between simple and complex extensions would be used to > > justify a constraint on the use of context in simple extensions, I > > would have objected to it. > > The problem is that readers of your xml that wish to store your data > in some form other than xml (relational database, triple store, > object oriented database, prolog database,...), and that may > not at the time of consumption know about your extension will save > the content in text, which is all the spec says they should do. Since > they don't at the time know the meaning of fh:prev and > in particular that it should contain a URI they can't save the > absolute URI it represents. > All they will be able to save is relative uri which will be > meaningless if the context of the > original document is lost.
The app should store the relative URI, and it shouldn't lose the context. > > > If you're using something like RDF to model feeds, you already have > > a number of context-related issues to work through, this isn't an > > extra burden. > > The point of making extensions is that they should be interpretable > or at least in part useable > by parties that don't understand the extension. It still is. > This is a question of the Atom spec saying that the content of a > simple extension element is character data. Yet you are now wishing > to put in relative references that have complex semantics > not completely understandable without having the original context of > the document they appear in. Lots of extensions will be like this. What's one itunes extenstion without the others? :) In summary, I agree with Mark. Robert Sayre
