In draft-ietf-atompub-format-11 under 4.2.7 The atom:link Element,
compare and contrast:
[[
4.2.7.4 The hreflang Attribute
The hreflang attribute's content describes the language of the
resource pointed to by the href attribute.
...
4.2.7.6 The length Attribute
The length
The approach I took in -04 was to say that the pseudo-ordering
introduced by the mechanism was ONLY meaningful for the purposes of
reconstituting the feed; it's still up to the feed itself to
determine what the ordering of entries means (or doesn't). That
avoids a lot of problems,
* Eric Scheid [EMAIL PROTECTED] [2005-10-14 17:35]:
Why would anyone want to know the 'last' link? One use case is
that one could take note of the 'last' URI, and then later find
out what the 'last' URI now is ... and if they are different
then obviously more has been added and it's time to
Lindsley Brett-ABL001 wrote:
I have a suggestion that may work. The issue of defining what is prev
and next with respect to a time ordered sequence seems to be a
problem. How about defining the link relationships in terms of time -
such as newer and older or something like that. That way, the
At 1:43 PM +0200 10/14/05, Danny Ayers wrote:
In draft-ietf-atompub-format-11 under 4.2.7 The atom:link Element,
compare and contrast:
[[
4.2.7.4 The hreflang Attribute
The hreflang attribute's content describes the language of the
resource pointed to by the href attribute.
...
On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote:
I have a suggestion that may work. The issue of defining what is
prev and next with respect to a time ordered sequence seems to
be a problem. How about defining the link relationships in terms of
time - such as newer and older or
On Oct 14, 2005, at 5:43 AM, Danny Ayers wrote:
I believe the language of the resource for hreflang makes no sense -
it will be the *representations* that are associated with languages,
and the implies a single language - there may be more than one.
If content negotiation might be used to
Mark Nottingham wrote:
How about:
atom:link rel=subscription href=.../
?
I always thought this was the role of @rel=self to give the URI you
should subscribe to, though re-reading the -11 it deals with a resource
equivalent to the containing element.
1. Isn't a resource equivalent to the
That's what I thought too, but the words in the spec don't bear it
out; a resource equivalent to the containing element is a little
hard to interpret (there is no equivalence function for Web
resources, by definition), but it's a lot closer to something you
dereference to get the same
On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote:
On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote:
I have a suggestion that may work. The issue of defining what is
prev and next with respect to a time ordered sequence seems to
be a problem. How about defining the link
On Oct 14, 2005, at 11:28 AM, Thomas Broyer wrote:
Mark Nottingham wrote:
How about:
atom:link rel=subscription href=.../
?
I always thought this was the role of @rel=self to give the URI
you should subscribe to, though re-reading the -11 it deals with a
resource equivalent to the
Mark Nottingham wrote:
I agree that it's important to honour the document order; that's what FH
tries to do. I'm a little surprised to hear you say that people thought
that this was previously 'next'; I'd never heard that (but will be happy
to put a note in).
Mark Pilgrim's article on
At first I really liked this proposal, but I think that the kind of
confusion you're concerned about is unavoidable; the terms you refer
to suffer bottom-up vs. top-down.
I think that defining the terms well and in relation to the
subscription feed will help; after all, the terms don't
Am 14.10.2005 um 20:00 schrieb James Holderness:
Mark Nottingham wrote:
Hmm. Yeah, I see what you're saying. Actually, I think this is an
opportunity -- we we define a new link relation to the subscription
document, and specify that it can only occur in archive documents, it
obviates the
On 10/14/05, Robert Sayre [EMAIL PROTECTED] wrote:
I don't understand the second issue being raised here. Could someone try
again?
Robert - sorry, I obviously wasn't very clear. I only wished to bring
a single issue to the list's attention, the discrepancy between the
wording of the spec on
+1
The meaning of these terms depends so much upon the feed it is being
used within. That and your own mental model.
If you visualize a feed like this:
---
|
|
|
|
|
|
|
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham
Sent:
I think that defining the terms well and in relation to the
subscription feed will help; after all, the terms don't surface in
UIs, so it should be transparent.
+1
Maybe this goes without saying, but I think the spec needs to either:
a) define these terms clearly and how they should be
On 10/14/05, Antone Roundy [EMAIL PROTECTED] wrote:
On Oct 14, 2005, at 11:13 AM, Mark Nottingham wrote:
On 14/10/2005, at 9:22 AM, Lindsley Brett-ABL001 wrote:
I have a suggestion that may work. The issue of defining what is
prev and next with respect to a time ordered sequence seems to
On Thu, 13 Oct 2005, A. Pagaltzis wrote:
Hi James,
* James M Snell [EMAIL PROTECTED] [2005-09-08 06:45]:
If anyone has any further comments on the draft, please let me
know.
I am alarmed that this draft does *not even once* explicitly
mention the fact that idrefs are expected to be derived
The way I look at this is in terms of a single linked list of feeds.
The ordering of the entries within those feeds is irrelevant. The
individual linked feeds MAY be incremental (e.g. blog entries,etc) or
may be complete (e.g. lists,etc). Simply because a feeds are linked, no
assumption
This looks good.
Is the 'first' the feed document that changes, whereas 'next' and 'last'
point to the archives? (in a feed history context?)
Henry
On Fri, 14 Oct 2005, James M Snell wrote:
The way I look at this is in terms of a single linked list of feeds. The
ordering of the entries
On 10/14/05, James M Snell [EMAIL PROTECTED] wrote:
The way I look at this is in terms of a single linked list of feeds.
James is 100% right. Think of any feed as a google search result,
ordered in terms of relevance. On your average blog, the newest post
is always the most relevant :). I
* James M Snell [EMAIL PROTECTED] [2005-10-15 00:25]:
Terms like top, bottom, up, down, etc are meaningless
in this model as they imply an ordering of the contents.
head/tail?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
What in the world is wrong with first and last? ;-) I just don't get it.
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-10-15 00:25]:
Terms like top, bottom, up, down, etc are meaningless
in this model as they imply an ordering of the contents.
head/tail?
Regards,
Right. A few questions that pop up:
1) Is it a closed or open set? If it's open (and I think 99% of feeds
are), what does last mean?
My answer is that it's probably an open set, so last doesn't mean
much that's useful (unless it's conflated with the subscription feed;
see below).
2)
This leads to:
Subscription feed:
- can contain link/@rel=prev, OR
- can contain fh:incremental = false
Archive feed:
- can contain link/@rel=prev and/or link/@rel=next
- can contain link/@rel=subscribe (effectively gives you last)
- link/@rel=subscribe has a semantic of if you want
Subscription feed:
- can contain link/@rel=prev, OR
- can contain fh:incremental = false
I never did understand this. Why is fh:incremental needed here? From a feed
history point of view you either have a history (a prev link is present) or
you don't. That's all an Atom processor needs
On 14/10/2005, at 8:01 PM, James Holderness wrote:
I never did understand this. Why is fh:incremental needed here?
From a feed history point of view you either have a history (a prev
link is present) or you don't. That's all an Atom processor needs
in order to reconstruct the feed.
I
Mark Nottingham wrote:
Right. A few questions that pop up:
1) Is it a closed or open set? If it's open (and I think 99% of feeds
are), what does last mean?
My answer is that it's probably an open set, so last doesn't mean
much that's useful (unless it's conflated with the subscription
On 15/10/05 8:28 AM, Henry Story [EMAIL PROTECTED] wrote:
Is the 'first' the feed document that changes, whereas 'next' and 'last'
point to the archives? (in a feed history context?)
My thinking is that of the two ends, 'first' and 'last', it would normally
be the 'first' end that is
On 14/10/2005, at 8:32 PM, James M Snell wrote:
1) Is it a closed or open set? If it's open (and I think 99% of
feeds are), what does last mean?
My answer would be: if last is used, it's a closed set; if last
is not used, it's an open set.
Can you walk me through a use case where
31 matches
Mail list logo
