Sunday, February 6, 2005, 3:10:23 AM, you wrote:
On 6/2/05 4:27 AM, David Powell [EMAIL PROTECTED] wrote:
Although we could keep the model we have (let's call it the 'mutable entries'
model), it isnt clear on a number of issues. Eg, if an old version of an
entry has some property that
On 5 Feb 2005, at 00:34, Robert Sayre wrote:
Antone Roundy wrote:
3.5 Identity Constructs
An Identity construct is an element whose content conveys a
permanent, universally unique identifier for the resource
(instantiated|described) by the construct's parent element. An Atom
Document MAY
On 5 Feb 2005, at 18:27, David Powell wrote:
I disagree, as I've said before. The only literal interpretation is
that you can't serve the same entry twice with the same id. We know it
doesn't mean that, but the spec just doesn't define in which axis
unique is meant to apply.
I think that the
On 6/2/05 4:27 AM, David Powell [EMAIL PROTECTED] wrote:
Although we could keep the model we have (let's call it the 'mutable entries'
model), it isnt clear on a number of issues. Eg, if an old version of an
entry has some property that isnt present in a newer version, does that
On Feb 4, 2005, at 11:56 AM, Bob Wyman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more
than
once in a single feed. (This rule is enforced by FeedValidator for
Atom 0.3
documents... Sam? Mark?)
Sounds
At 2:56 PM -0500 2/4/05, Bob Wyman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed.
The current draft says:
5.8 atom:id Element
The atom:id element is an Identity
* Paul Hoffman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed.
The current draft says:
5.8 atom:id Element
The atom:id element is an Identity construct that
On Feb 4, 2005, at 12:29 PM, Paul Hoffman wrote:
At 2:56 PM -0500 2/4/05, Bob Wyman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more
than
once in a single feed.
The current draft says:
5.8 atom:id
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:
I.e., just because it's a permanent, universally unique identifier
doesn't mean you're not able to use it twice to talk about a single
entry;
I disagree, as I've said before. The only literal interpretation is
that you can't serve the same entry
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any two
entries, ever.
I don't read it that way, although I understand how you might infer
that; there's too much wiggle room in the current text for that intent
to be clear.
I.e.,
Bjoern Hoehrmann wrote:
It does not mean that once cannot have multiple versions of the same
entry in a feed (or duplicate entries for that matter).
Conversely it does imply that if you do, you may (and possibly, must)
assume that they are the same entry.
The problem: there's no easy way to
Graham wrote:
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:
I.e., just because it's a permanent, universally unique identifier
doesn't mean you're not able to use it twice to talk about a single
entry;
I disagree, as I've said before. The only literal interpretation is that
you can't serve
A really clear way to specify this is to say that an id is a functional
relation between
an entry and a identity construct.
This implies:
-An Entry can only have one id.
-Different Entries can have the same id.
Of course because there is a bit of a confusion as to what is meant by
an Entry
On 4 Feb 2005, at 9:10 pm, Mark Nottingham wrote:
Separately, there's the issue of what it *should* say. Tim and now you
say that you have a good idea of what you want it to say; I'd be very
interested to see how you'd specify that. Can you suggest some spec
text?
As I suggested a couple of
Tim Bray wrote:
I'm with Mnot on this one. Just because it uniquely identifies an
entry, that doesn't mean you can't have two versions of the same
entry in a feed. ... I don't see any reason for ruling them out in a
single feed.
Robert Sayre wrote:
We should probably be more worried about bad
On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote:
The term version seems out of place here. What you're saying, in
effect, is that the ID acts as a hash of entry's content, correct? If,
so, what value does it bring?
Pardon:
Any two versions of the same entry must use the same id, [which
On Friday, February 4, 2005, at 02:05 PM, Tim Bray wrote:
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any
two entries, ever.
I don't read it that way, although I understand how you might infer
that; there's too much wiggle
When you talk about characters being the same or different, are you
saying in the entry, or in the id?
On Feb 4, 2005, at 2:18 PM, Graham wrote:
On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote:
The term version seems out of place here. What you're saying, in
effect, is that the ID acts as a
On 4 Feb 2005, at 10:32 pm, Mark Nottingham wrote:
When you talk about characters being the same or different, are you
saying in the entry, or in the id?
Oh, right. The id. That would be clear if the things in brackets were
expanded (since same and different ids also need defining).
Graham
At 1:05 PM -0800 2/4/05, Tim Bray wrote:
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any
two entries, ever.
I don't read it that way, although I understand how you might infer
that; there's too much wiggle room in the current
Paul Hoffman wrote:
That means that you're not allowed to [use] the same atom:id in any
two entries, ever.
We have atom:modified in order to indicate that an instance is a
modified version of a previously published entry. The linkage between the
two instances of the entry is that they
On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote:
An Identity construct is an element whose content conveys an
unchanging identifier which MUST be universally unique within Atom
Documents to the set of all versions and instantiations of the
resource that the construct's parent
Antone Roundy wrote:
3.5 Identity Constructs
An Identity construct is an element whose content conveys a permanent,
universally unique identifier for the resource (instantiated|described)
by the construct's parent element. An Atom Document MAY contain
multiple (revisions|versions) of the same
Just a note; I'm planning to remove the Identity Construct from -06,
because it's only used in one place (the definition of atom:id).
Otherwise, this sounds like a reasonable start.
On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote:
On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote:
On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote:
On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote:
An Identity construct is an element whose content conveys an
unchanging identifier which MUST be universally unique within Atom
Documents to the set of all versions and
Hoffman'; 'Atom WG'
Subject: Re: Call for final Paces for consideration: deadline imminent
On Feb 4, 2005, at 2:43 PM, Bob Wyman wrote:
Paul Hoffman wrote:
That means that you're not allowed to [use] the same atom:id in any
two entries, ever.
We have atom:modified in order to indicate
On 3/2/05 7:18 PM, Robert Sayre [EMAIL PROTECTED] wrote:
This is better. I guess I just hadn't grok'd the idea of using
entries to reference feeds, but now that I see the angle brackets I
get it.
Yes, feeds are entries.
no, feeds are collections, entries describe resources, and while
On Feb 2, 2005, at 5:46 PM, Paul Hoffman wrote:
...
On Monday, Feb. 7, the Working Group's final queue rotation will
consist of all Paces open at that time. Any Paces that have obvious
holes in them (to be filled in later, more needs to go here, etc.)
will be ignored. We have had over a year of
Walter brings up an important point; has, or when will, the drafts be
compared to the requirements in the charter?
Cheers,
On Feb 2, 2005, at 8:36 PM, Walter Underwood wrote:
The charter says that Atom will work for archiving. We don't know that
it will, and it hasn't been discussed for months.
Greetings again. And, thanks again for all the work people did on the
last work queue rotation. We now have the end of the format draft
squarely in sight.
The WG still has a bunch of finished Paces that have not been
formally considered, a (thankfully) much smaller number of unfinished
Paces,
Paul Hoffman wrote:
Please do *not* rush out to write a Pace unless it is for something that
is *truly* part of the Atom core, and you really believe that it is
likely that there will be consensus within a week.
Sorry, this is not a legitimate condition. If someone writes a Pace that
points
At 9:57 PM -0500 2/2/05, Robert Sayre wrote:
Paul Hoffman wrote:
Please do *not* rush out to write a Pace unless it is for something
that is *truly* part of the Atom core, and you really believe that
it is likely that there will be consensus within a week.
Sorry, this is not a legitimate
On 3/2/05 4:01 PM, Robert Sayre [EMAIL PROTECTED] wrote:
4.) Atom sucks at blogs with comments or trackbacks
5.) Atom sucks at anything with a representation of its own and
collection membership
link href=... type=application/atom+xml rel=comments /
link href=... type=application/atom+xml
+1 Eric. sub-feeds can easily be nested by reference using the
existing link mechanism as opposed to nesting by containment. Overall
this would be a cleaner model and would be easier on bandwidth by
allowing nested feeds to be broken up over several documents rather
than stuffed all into a
Comments below..
On Thu, 03 Feb 2005 17:27:33 +1100, Eric Scheid
[EMAIL PROTECTED] wrote:
On 3/2/05 5:09 PM, James Snell [EMAIL PROTECTED] wrote:
What is the model for archiving with Atom? One or more distinct Atom
feeds that each contain a collection of old entries? If so, what we
35 matches
Mail list logo
