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.
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. RDF has nothing to do
with this. (Other than
it having some very solid theoretical backing and so being very
helpful in thinking about these
issues, and also of it having solved quite a few years ago the
problems that you are just discovering)
I should explicitly allow relative URIs in fh:prev, though.
-1
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.
I know it may seem to the writer of an extension as if the meaning of
his extension were clear
as day, but this will not be the case to all consumers of your
extension, and even if your
extension becomes world famous, it certainly won't be true for all
the other extensions that people will come up with. So I think we
should be setting a good example in these first extensions we write.
Henry Story
Cheers,
On 16/08/2005, at 11:35 AM, Henry Story wrote:
I think that in section 5. you should specify that the URI
reference MUST NOT be relative or
MUST BE absolute (if that is the proper W3C Architecture term). I
agree with the point made by
David Powell in the thread entitled "More about extensions" [1].
Given that we have this problem I was wondering whether it would
not be better
to use the link element as I think it permits relative references.
Relative references
really are *extreemly useful*. I tried to work without them in my
BlogEd editor
because the Sesame database folk mistakenly thought it was not
part of RDF, and it caused
me no end of trouble: all those problems vanished as soon as they
allowed relative references.
So if relative references are allowed in links perhaps the
following would be better:
<link type="http://purl.org/syndication/history/1.0/next"; href="./
archives/archive1.atom">
Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html
On 15 Aug 2005, at 22:31, Mark Nottingham wrote:
Draft -03 of feed history is now available, at:
http://www.ietf.org/internet-drafts/draft-nottingham-atompub-
feed-history-03.txt
Significant changes in this revision include:
- add fh:archive element, to indicate that an entry is an archive
- allow subscription feed to omit fh:stateful if fh:prev is
present
- clarified that fh doesn't add ordering semantics, just allows
you to reconstruct state
- cleaned up text, fixed examples, general standards hygiene
There's going to be at least one more draft, as I neglected to
acknowledge people who have made suggestions and otherwise helped
so far. Sorry!
--
Mark Nottingham http://www.mnot.net/
--
Mark Nottingham http://www.mnot.net/
