Don't you have the same problem with atom:modified? What if the
publisher does not update the atom:modified entry?
I suppose that if you are making an archive of an atom entries and
believe
that the author has made a mistake with the atom:updated field, you can
of course try to correct the
At 7:56 AM -0400 5/12/05, Scott Hollenbeck wrote:
It would be helpful if you could address the The current draft fails to
satisfy the second bullet point allegation.
-Scott-
-Original Message-
From: Robert Sayre [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 11, 2005 2:00 PM
To:
Gah! What is the true atom:updated for the following entry?
feed
updated2005-05-12T02:22:59+/updated
author.../author
copyright.../copyright
entry
updated2005-05-11T01:11:59+/updated
id.../id
summary.../summary
title.../title
/entry
Gah! What is the true atom:updated for the following entry?
Eric: The entry-level version, IMO.
--
Roger Benningfield
Is this legal according to our spec-08?
link rel=foo bar .../
According to the spec, @rel can contain either isegment-nz-nc or IRI values,
where isegment-nz-nc is also described as atomNCName, which is defined in
Appendix B (RELAX NG Compact Schema) as
atomNCName = xsd:string {
Thus spake RFC 2119:
3. SHOULD This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
At 11:18 PM
Paul Hoffman wrote:
Thus spake RFC 2119:
3. SHOULD This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different
On 5/12/05, Paul Hoffman [EMAIL PROTECTED] wrote:
Thus spake RFC 2119:
3. SHOULD This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
David Powell wrote:
I'm in favour of allowing duplicate ids. This only seems to be a
partial solution though:
Their atom:updated timestamps SHOULD be different
But what if they are not? What if I want to represent an archive of a
feed - maybe mine, maybe someone else's - but the atom:updated
On 12/5/05 5:26 PM, Henry Story [EMAIL PROTECTED] wrote:
Don't you have the same problem with atom:modified? What if the
publisher does not update the atom:modified entry?
Theoretically, the publisher doesn't get that choice. To not update
atom:modified would be an error.
There remains the
On Thursday, May 12, 2005, at 12:20 PM, Thomas Broyer wrote:
Eric Scheid wrote:
Gah! What is the true atom:updated for the following entry?
feed
updated2005-05-12T02:22:59+/updated
author.../author
copyright.../copyright
entry
updated2005-05-11T01:11:59+/updated
On Thursday, May 12, 2005, at 12:32 PM, Julian Reschke wrote:
Paul Hoffman wrote:
At 7:16 PM +0200 5/12/05, Julian Reschke wrote:
A receiving implementation must be able to handle all defined
elements, regardless if they are defined as MAY sent, SHOULD send,
or MUST send, so I'm not sure what
At 8:32 PM +0200 5/12/05, Julian Reschke wrote:
Bare with me here; I'm not an implementer. What kind of pseudocode
are you envisioning on the receiver side? My picture (which could
easily be wrong is):
# Atom 1.0 RFC says entries MUST have exactly one atom:foo1
# Atom 1.0 RFC says entries
On 13/5/05 4:30 AM, Antone Roundy [EMAIL PROTECTED] wrote:
From 4.2.9.2 The rel Attribute:
The value of rel MUST be string that is non-empty, and matches the
isegment-nz-nc or IRI production in [RFC3987].
If I'm reading RFC3987 correctly, isegment-nz-nc does not include
spaces,
hmmm -
On 13/5/05 4:39 AM, Antone Roundy [EMAIL PROTECTED] wrote:
Eric, was your point that the entry might be inheriting data from the
feed which was updated after the entry was updated, and therefore, the
entry might be thought of as having been updated after it's atom:updated
timestamp? Other
On 13/5/05 5:07 AM, Antone Roundy [EMAIL PROTECTED] wrote:
If you find more than one atom:foo2, fail. Process the atom:foo2 if it
exists.
...should be this instead:
If you find more than one atom:foo2, fail. If you don't find an
atom:foo2, you are allowed to fail and still call yourself
Julian Reschke wrote:
Paul Hoffman wrote:
Why not? If the text says something to the effect of, for example,
SHOULD include an atom:summary element unless there really is no
summary, then title-only feeds are fine.
:-)
Adding unless there really is no summary of course changes the meaning
in
On 13/5/05 5:14 AM, Julian Reschke [EMAIL PROTECTED] wrote:
Why not? If the text says something to the effect of, for example,
SHOULD include an atom:summary element unless there really is no
summary, then title-only feeds are fine.
:-)
Adding unless there really is no summary of course
At 1:07 PM -0600 5/12/05, Antone Roundy wrote:
On Thursday, May 12, 2005, at 12:32 PM, Julian Reschke wrote:
Paul Hoffman wrote:
At 7:16 PM +0200 5/12/05, Julian Reschke wrote:
A receiving implementation must be able to handle all defined
elements, regardless if they are defined as MAY sent,
Eric Scheid wrote:
so I think @rel as spec'd can only contain one value and no
whitespace.
but that then means isegment-nz-nc != atomNCName
atomNCName = xsd:string { minLength = 1 pattern = [^:]* }
which is easy to fix
atomNCName = xsd:string { minLength = 1 pattern = [^: ]* }
The RNC is
People seem confused about RFC 2119.
If it helps, here is an example. But, be aware, it is JUST an example
at this point. I'd like to be able to discuss it without people
questioning each other's commercial viability, personal relevance to
this process, or talking about things caching fire or
On 12 May 2005, at 18:49, Eric Scheid wrote:
On 13/5/05 2:04 AM, Roger B. [EMAIL PROTECTED] wrote:
Gah! What is the true atom:updated for the following entry?
Eric: The entry-level version, IMO.
What if an atom processor had previously seen that entry with that
atom:updated ... should it do
On 13/5/05 7:12 AM, Henry Story [EMAIL PROTECTED] wrote:
Just to recapitulate: we have 2 feed documents with successive atom updated
values, and with the same entry (same id) with the same time stamp but some
values that are not identical. Does the newer feed document trump the older
one?
Eric Scheid wrote:
I agree. You can see how easy it would be to not do that though. It could
also be argued that the publisher has signalled the significance by updating
/feed/updated, and thus effectively /feed/entry/. The ambiguity bothers me.
thus effectively, does not follow. That's not
Friday, May 6, 2005, 3:52:19 PM, Eric Scheid wrote:
On 7/5/05 12:09 AM, Graham [EMAIL PROTECTED] wrote:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MUST treat them as multiple versions of the same
entry
I don't think this changes the technical
In Section 4.2.15:
Publishers MAY change the value of this element over time.
This sentence seems pretty obvious. It could be said about atom:title,
or any of the fields. Does it have some subtle meaning that I am
missing?
--
Dave
26 matches
Mail list logo
