Tim Bray wrote:
On Jul 17, 2005, at 8:16 AM, Sam Ruby wrote:
Upon further reading of 3986, I'm convinced that Tim's current feed
is correct.
I think so too, but I'm worried how XML-reader implementations will do
supporting all this base-URI stacking. If this kind of thing is going
Sorry I did not participate in the previous discussion for format 00.
I only just
realized this was going on. What is clear is that this is really needed!
I agree with Stefan Eissing's random thought that it may not be a
good idea to use
Atom for a top 10 feed. Atom entries are not ordered
Henry Story wrote:
Sorry I did not participate in the previous discussion for format 00.
I only just
realized this was going on. What is clear is that this is really needed!
I agree with Stefan Eissing's random thought that it may not be a
good idea to use
Atom for a top 10 feed. Atom
On 18/07/2005, at 11:10 AM, James M Snell wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define
that an empty fh:prev (refering to itself) is the last document
in a stateful feed. That would eliminate the
Mark Nottingham wrote:
On 18/07/2005, at 11:10 AM, James M Snell wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define that
an empty fh:prev (refering to itself) is the last document in a
stateful feed.
There is precedence for using atom:link in RSS feeds. see
http://feeds.feedburner.com/ITConversations-EverythingMP3. I really
don't think it's a problem.
Mark Nottingham wrote:
That's what I originally did, but I have a rather strong preference
to make a single syntax work in RSS and
On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also
do the job. However this still means that clients need to check the
first
A. Pagaltzis wrote:
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-18 11:50]:
Yes, your link href= / resolves to
http://www.tbray.org/ongoing/ But if you say follow that link
in a program with same-document references support, it will
say: Ok, the link points to http://www.tbray.org/ongoing/,
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also do
the job. However this still means that clients need to check the first
fh:prev document if they know all entries there - if my
On 7/18/05, Robert Sayre [EMAIL PROTECTED] wrote:
Media RSS already has an effective editor who is also a good listener:
Yahoo's David Hall. If the Media RSS folks (or some other constituency
who've done their homework) want to use this WG as their venue, that
would be great. If not, I would
On 18/07/2005, at 1:29 PM, Stefan Eissing wrote:
I agree that special URIs are not that great either. Another idea
might be nested elements:
stateful feed: fh:historyfh:prevhttp://example.org/thingie1.1/
fh:prev/fh:history
stateful initial feed: fh:history/
stateless feed:
Am 18.07.2005 um 19:33 schrieb Mark Nottingham:
On 18/07/2005, at 1:29 PM, Stefan Eissing wrote:
I agree that special URIs are not that great either. Another idea
might be nested elements:
stateful feed:
fh:historyfh:prevhttp://example.org/thingie1.1/fh:prev/fh:
history
stateful
Heh... the same questions could be asked about a lot of stuff embedded
in RSS but that's not the issue ;-) ... fh:prev works fine. There
really isn't a strong argument in favor of link. I have my own personal
preferences but those are actually quite irrelevant :-)I'll still
maintain
Am 18.07.2005 um 18:59 schrieb James M Snell:
Mark Nottingham wrote:
On 18/07/2005, at 11:10 AM, James M Snell wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define
that an empty fh:prev (refering to
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 01:25]:
A. Pagaltzis wrote:
He is correct, Tim. The base URI means “the URL where this
document was found,” not “the prefix for any enclosed relative
links.” I don’t see how RFC3986 can be read any other way.
I am correct ;), but your
A. Pagaltzis wrote:
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 01:25]:
A. Pagaltzis wrote:
He is correct, Tim. The base URI means “the URL where this
document was found,” not “the prefix for any enclosed relative
links.” I don’t see how RFC3986 can be read any other way.
I am correct
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 03:15]:
That is my interpretation too, but only through the way the
base URI is used. I can't find any hint in that direction
otherwise. It would be nice if T. Berners-Lee, R. Fielding or
L. Masinter could confirm that. If it would have been
17 matches
Mail list logo
