On 16 Aug 2005, at 21:50, Robert Sayre wrote:
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.
relative URI? The application we are speaking about knows nothing of
a relative
uri. All you have inside your Simple Extension Element is text! See
the spec 6.4.1.
An application that does not know your extension cannot know that the
text inside
your extension is to be interpreted as a relative uri. So what you
are saying is
that any application that wants to process atom with extension
elements has to keep
the full context of the document in which they found the extension
element, even if
the document is a 100s of Megabytes long, and even if there is only
one extension
element inside of it! Or take the case of code that wants to place
the feed inside
some other xml, which has a base element. What is it to do when it
finds an extension
element it does not understand?
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.
No they are not! See the 2 examples above.
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.
You agree to accept the problems that go with his position, yes.
But why bother when there clearly is an easy solution to the problem
that works with
the current atom format and which I outlined earlier, namely using
the link element.
I suggested writing the next tag like this:
<link type="http://purl.org/syndication/history/1.0/next"; href="./
archives/archive1.atom">
This clearly allows relative uris (if I am not mistaken) without any
of the problems
we have with the simple extension elements. And it seems to be
exactly this type of
thing that the link element was designed to do.
Henry Story
http://blogs.sun.com/roller/page/bblfish/
Robert Sayre
