On Feb 6, 2005, at 01:48, Graham wrote:
Change second sentence of:
The "atom:updated" element is a Date construct indicating the most
recent instant in time when an entry or feed was modified in a way
the producer considers significant. Therefore, not all
modifications
necessarily res
-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to try to
rush through something this major at the last moment before a pending Last
Call.
bob wyman
My challenge with the idea of mustUnderstand in Atom is in trying to
figure out how the heck it would realistically be used for anything
worthwhile. Take blog content for instance, if my blog reader accesses
a feed that contains an entry with a mustUnderstand metadata element
that my reader does n
Hmm.. I'm sorry but this just seems wierd to me.
...
id:version1
id:version2
id:version3
What is the point of having the feed elements in there at all? If
entries are indeed able to stand on their own, why not just go ahead and
I'd rather have held off while we discussed further, but as the
deadline is approaching, here it is.
Abstract
Creates a new option for the document element, , which can
contain multiple feeds or instances of the same feed, in order to
archive the states of a feed or feeds and the states of the
consider
assume for the moment that is a valid scheme
is that kind of URI something we want to allow in link/@href?
putting it another way, look closely at this example
[...]
http://example.com/892379587493
http://example.com/2005/02/mut
On 6 Feb 2005, at 4:17 am, Eric Scheid wrote:
On 6/2/05 3:28 AM, "Graham" <[EMAIL PROTECTED]> wrote:
1. In order to show the revision history of a particular entry,
multiple revisions of the entry must be able to appear in the same
document.
But "must" we have this facility?
your other options a
On 6/2/05 10:53 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:
> atom:feed and atom:entry elements MAY have a "profile" attribute whose
> value is a list of names or URI's identifying one or more metadata
> profiles that have been applied to the feed or entry. A profile is a
> description what m
On 6/2/05 10:48 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> Therefore, other modifications SHOULD NOT result in a changed
> atom:updated value.
+1
e.
On 6/2/05 9:55 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> I would prefer a solution whereby if somebody wants to include versions
> of entries into a feed they need to include a version specific
> identifier.
+1.
e.
On 6/2/05 9:38 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> I am +1 on the regular expression limitation,
> believe that all dates that that conform to this limitation are valid
> RFC 3339 and xsd:dateTime values, and believe that it will interop with
> all of the existing XSD implementations.
wh
On 6/2/05 8:41 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> If
> anything we should address the lack of a standard method for creating
> atom:id's and we should create a requirement that atom:updated must be
> changed on *every* update -- not just on the whim of the entry author...
arrgh!
atom:
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 5, 2005, at 9:48 AM, Mark Nottingham wrote:
What does that mean? SOAP is a "Must Ignore format," but it also has a
way of saying that you have to understand a particular extension; as I
said before, this is one of the big problems with HTTP. mustUnderstand
should be used sparingly, but so
Antone Roundy wrote:
This would not address your question of tracking changes to the feed's
metadata. I'd be perfectly happy with not allowing atom:id to be
repeated in a or the hypothetical if we had an
element which acts exactly like except that
atom:id may be repeated.
Nah, overkill. I
On Saturday, February 5, 2005, at 06:25 PM, Antone Roundy wrote:
I'd be perfectly happy with not allowing atom:id to be repeated in a
or the hypothetical if we had an
element which acts exactly like except that atom:id may
be repeated.
Oops, correction: I'd be perfectly happy with not allo
On Saturday, February 5, 2005, at 02:07 PM, Robert Sayre wrote:
Antone Roundy wrote:
On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote:
Part of our charter is to define a format suitable for archiving
feeds.
Right, and breaking the feed format isn't the way to do it. Since
you're
On Saturday, February 5, 2005, at 03:55 PM, Sam Ruby wrote:
-1 to the Pace.
Just to be sure we don't forget, if we don't want to allow multiple
versions of an entry in the same feed document, we need to add language
to the spec to clarify that point.
Like Robert, I believe that this Pace breaks
Graham wrote:
#pragma section-numbers off
== Abstract ==
Clarify when not to update atom:updated
+1
cheers
Bill
> Having written the datetime support for Apache Axis (a
> webservice implementation based on XSD schema and having
> hosted a number of SOAP interop facilities, I am +1 on the
> regular expression limitation, believe that all dates that
> that conform to this limitation are valid RFC 3339 and
This is a modified version of Mark Nottingham's initial idea that
reflects my thinking on the subject as developed through the mailing
list discussion. I posted it as PaceProfileAttribute as opposed to
Mark's initial PaceProfile in case he wanted to go ahead and attempt to
submit his original
#pragma section-numbers off
== Abstract ==
Clarify when not to update atom:updated
== Status ==
Open
== Rationale ==
The second sentence ("not all modifications...") is a bit vague and
conceivably contradicts the first (which implies "only some", second
implies "most"). NB This is not an attempt
Robert Sayre wrote:
Antone Roundy wrote:
Neither of these is equivalent to atom:id--according to this text, the
{item_uri} and rdf:about for a particular item could change each time
you transmit the feed. Whether we accept this Pace or not, that is
not what is intend for atom:id. Could you exp
Norman Walsh wrote:
/ Tim Bray <[EMAIL PROTECTED]> was heard to say:
| I tend to agree as well; in this case, the fact that this is an XML
| vocabulary is probably more relevant than the fact that it's an IETF
| RFC. So can we please have a Pace to call out to XSD? I'm pretty
Done. PaceDatesXSD
-
Bob Wyman wrote:
It is all this informality and hand-waving around atom:id and
atom:updated that is the source of any trouble with using atom:feed as an
archive format. Given globally unique ids (atom:id) and version tags
(atom:updated) for entries, archiving would be trivial even for "igno
Bob Wyman wrote:
Robert Sayre wrote:
Bob Wyman wrote:
As long as multiple instances/versions of an entry are permitted to
exist in a single atom document while sharing the same atom:id, the
current Atom document format provides a useable "archive format."
This is clearly a non-starter for a synd
Robert Sayre wrote:
>> Bob Wyman wrote:
>> As long as multiple instances/versions of an entry are permitted to
>> exist in a single atom document while sharing the same atom:id, the
>> current Atom document format provides a useable "archive format."
> This is clearly a non-starter for a sy
Norman Walsh wrote:
/ Robert Sayre <[EMAIL PROTECTED]> was heard to say:
| I would tend to agree. Can we have that regex go in the Pace itself?
The regex is in the pace.
I took the liberty of adding it to the proposal section.
Robert Sayre
/ Robert Sayre <[EMAIL PROTECTED]> was heard to say:
| I would tend to agree. Can we have that regex go in the Pace itself?
The regex is in the pace.
Be seeing you,
norm
--
Norman Walsh <[EMAIL PROTECTED]> | Life
Robert Sayre wrote:
I would tend to agree. Can we have that regex go in the Pace itself?
That would make the proposal pretty much editorial, since the set of
allowed timestamps would be the same (right?).
As long as the set of allowed timestamps and their semantics is the
same, that's fine with
Antone Roundy wrote:
On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote:
Part of our charter is to define a format suitable for archiving feeds.
Right, and breaking the feed format isn't the way to do it. Since
you're advocating versioning, what are your plans for versioning the
sta
Julian Reschke wrote:
Risking that I sound like a broken report...: xsd:dateTime allows a
superset of what we can represent in RFC3339 (I'm talking about
semantics, not syntax here). So if we *don't* profile it, the spec will
need to explain how to obtain an ordering from a set of atom:updated
Graham wrote:
> You're shockingly small-minded sometimes Tim.
Do we really need to have this stuff in this forum?
The Macintouch and BBC News feeds that you provide as examples
simply demonstrate that there is a need for some mechanism to specify order
relationships between entrie
* Tim Bray wrote:
>I tend to agree as well; in this case, the fact that this is an XML
>vocabulary is probably more relevant than the fact that it's an IETF
>RFC. So can we please have a Pace to call out to XSD? I'm pretty sure
>that implementors would just use the libraries and The Right Thi
/ Tim Bray <[EMAIL PROTECTED]> was heard to say:
| I tend to agree as well; in this case, the fact that this is an XML
| vocabulary is probably more relevant than the fact that it's an IETF
| RFC. So can we please have a Pace to call out to XSD? I'm pretty
Done. PaceDatesXSD
Tim Bray wrote:
On Feb 5, 2005, at 11:46 AM, Asbjørn Ulsberg wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema
Danny Ayers wrote:
> The killer problem of using doc order is that the feed data *will*
> be aggregated and republished.
Precisely! As the blogosphere grows and as the number of feeds grow,
I feel it is inevitable that we are simply going to have to give up the
current "feed-oriented" focu
Antone Roundy wrote:
> A number of people in the working group have expressed a desire to
> be able to archive the revision history of an entry--not just the
> latest version--which is a fairly natural thing to want to do with
> an archive format. That's not something any RSS version has
> attemp
On Feb 5, 2005, at 11:46 AM, Asbjørn Ulsberg wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2 than RFC
On Feb 5, 2005, at 10:28 AM, Bill de hÓra wrote:
You're shockingly small-minded sometimes Tim.
Rudeness objection.
Hey, I'm used to 8 flames before breakfast from Graham compared to
which that was a sweet nothing. He hasn't called me "criminally
insane" in months and months. I note that in rece
On Fri, 04 Feb 2005 11:18:17 -0500, Norman Walsh <[EMAIL PROTECTED]> wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XM
On 5 Feb 2005, at 20:18, Bob Wyman wrote:
Roger Benningfield wrote:
Henry: I suspect that Bob's reaction would have been the same, no
matter how well-defined the extension mechanism. Anything outside
the core will have spotty (at best) support in aggregators and
publishing tools.
You are absolutel
Roger Benningfield wrote:
> Henry: I suspect that Bob's reaction would have been the same, no
> matter how well-defined the extension mechanism. Anything outside
> the core will have spotty (at best) support in aggregators and
> publishing tools.
You are absolutely correct. While I think
On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote:
Part of our charter is to define a format suitable for archiving
feeds.
Right, and breaking the feed format isn't the way to do it. Since
you're advocating versioning, what are your plans for versioning the
state of the feed itself
Danny Ayers wrote:
> The motto that spontaneously emerged on this list was
> "It's the Entries, stupid!" - comments and trackbacks are just
> entries too, only with different metadata. Is there something else here?
I strongly agree that "comments and trackbacks are just entries
too..." G
On 5 Feb 2005, at 19:48, Robert Sayre wrote:
Antone Roundy wrote:
Neither of these is equivalent to atom:id--according to this text,
the {item_uri} and rdf:about for a particular item could change each
time you transmit the feed. Whether we accept this Pace or not, that
is not what is intend f
On Saturday, February 5, 2005, at 11:20 AM, Bill de hÓra wrote:
Antone Roundy wrote:
-1 also. I think we'd do better to focus on the specification text
for id - that will be much more effective than adding qualifying
text. I think it falls under editorial work and requires no pace.
I have no i
Antone Roundy wrote:
Neither of these is equivalent to atom:id--according to this text, the
{item_uri} and rdf:about for a particular item could change each time
you transmit the feed. Whether we accept this Pace or not, that is not
what is intend for atom:id. Could you explain how these are i
Graham wrote:
On 5 Feb 2005, at 4:40 pm, Tim Bray wrote:
I totally can't think of a reasonable use-case in which preserving the
feed order matters.
- The Macintouch feed is ordered in the same way as the home page, and
makes no sense viewed chronologically
- The BBC News feeds have the most impo
Sigh indeed. We have only one chance to do this. This was one of the
big advantages that I was looking for Atom to have over RSS...
On Feb 5, 2005, at 10:18 AM, Tim Bray wrote:
On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote:
What does that mean? SOAP is a "Must Ignore format," but it also has
Tim Bray wrote:
-1
Consider this sentence:
"The construct can be interpreted as a simple property of its
Subject. The pair consisting of the namespace-URI of the element
and the local name of the element can be interpreted as the name of
the property. "
It will make NO SENSE WHATEVER to som
Antone Roundy wrote:
-1 also. I think we'd do better to focus on the specification text for
id - that will be much more effective than adding qualifying text. I
think it falls under editorial work and requires no pace.
I have no idea what you mean by this comment.
I mean this:
1. I believe t
On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote:
What does that mean? SOAP is a "Must Ignore format," but it also has a
way of saying that you have to understand a particular extension; as I
said before, this is one of the big problems with HTTP. mustUnderstand
should be used sparingly, but so
On 5 Feb 2005, at 18:48, Mark Nottingham wrote:
On Feb 5, 2005, at 4:38 AM, Henry Story wrote:
You put this in terms of databases and I put the question in terms of
graphs (which if you
have an rdf database to store your triples comes to the same thing).
And my feeling is here that we should not
-1
Consider this sentence:
"The construct can be interpreted as a simple property of its
Subject. The pair consisting of the namespace-URI of the element
and the local name of the element can be interpreted as the name of
the property. "
It will make NO SENSE WHATEVER to someone who isn't h
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 pro
On Feb 5, 2005, at 4:38 AM, Henry Story wrote:
You put this in terms of databases and I put the question in terms of
graphs (which if you
have an rdf database to store your triples comes to the same thing).
And my feeling is here that we should not have to keep the sequence
numbers of the
order
On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote:
On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham <[EMAIL PROTECTED]>
wrote:
My preference would be something like
This specification assigns no significance to the order of atom:entry
elements within an Atom Feed Document. Atom Processors MAY pres
On Saturday, February 5, 2005, at 10:25 AM, Robert Sayre wrote:
Antone Roundy wrote:
1. In order to show the revision history of a particular entry,
multiple revisions of the entry must be able to appear in the same
document.
2. Changing the atom:id of the entry with each revision would
s
>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 problem is that the term 'en
I think it is a problem, I'm not near a PC this weekend though. I'll try to
write a Pace on Sunday night that will make it explicit what xml:lang applies
to.
>Have you had any more luck with this part of the mapping? Is this a
>problem with the current Atom syntax if not?
>
>Henr
On Saturday, February 5, 2005, at 10:00 AM, Bill de hÓra wrote:
Graham wrote:
2. Changing the atom:id of the entry with each revision would
severly reduce the duplicate detection value of atom:id.
I don't think anyone's proposed this.
-1
Wrong: http://www.imc.org/atom-syntax/mail-archive/msg13
Antone Roundy wrote:
1. In order to show the revision history of a particular entry,
multiple revisions of the entry must be able to appear in the same
document.
2. Changing the atom:id of the entry with each revision would severly
reduce the duplicate detection value of atom:id.
-1.
RSS1
Tim Bray wrote:
I'm +1 on both Mark and Joe's version, slightly stronger on Joe's
because I don't think we need drag extensions in.
"This specification assigns no significance to the order of atom:entry
elements within an Atom Feed Document. Atom Processors MAY present
entries in any order, inc
* Tim Bray <[EMAIL PROTECTED]> [2005-02-05 08:40-0800]
>
>
> On Feb 5, 2005, at 5:36 AM, Danny Ayers wrote:
>
> >
> >On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
> >
> Ordering of the element children of atom:feed element MUST NOT be
> considered significant.
On 5 Feb 2005, at 2:26 pm, Joe Gregorio wrote:
How is any of this useful in a normative document?
"""The order of atom:entry elements is typically in reverse
chronological order
What does this tell who?
though feeds MAY be constructed with entries in any order
This is just about useful.
and this sp
On Saturday, February 5, 2005, at 09:42 AM, Tim Bray wrote:
On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote:
On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham <[EMAIL PROTECTED]>
wrote:
This specification assigns no significance to the order of atom:entry
elements within an Atom Feed Document. At
Graham wrote:
2. Changing the atom:id of the entry with each revision would
severly reduce the duplicate detection value of atom:id.
I don't think anyone's proposed this.
-1
-1 also. I think we'd do better to focus on the specification text for
id - that will be much more effective than addin
On 5 Feb 2005, at 4:40 pm, Tim Bray wrote:
I totally can't think of a reasonable use-case in which preserving the
feed order matters.
- The Macintouch feed is ordered in the same way as the home page, and
makes no sense viewed chronologically
- The BBC News feeds have the most important stories f
On Feb 5, 2005, at 5:36 AM, Danny Ayers wrote:
On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
Ordering of the element children of atom:feed element MUST NOT be
considered significant.
+1.
+1 - I don't care whether we say "MUST NOT", or the other wording
floating around ab
On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote:
On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham <[EMAIL PROTECTED]>
wrote:
This specification assigns no significance to the order of atom:entry
elements within an Atom Feed Document. Atom Processors MAY present
entries in any order, unless a spec
On 5 Feb 2005, at 4:18 pm, Antone Roundy wrote:
1. In order to show the revision history of a particular entry,
multiple revisions of the entry must be able to appear in the same
document.
But "must" we have this facility?
2. Changing the atom:id of the entry with each revision would
sever
On 5 Feb 2005, at 13:49, Henry Story wrote:
So perhaps what we could do in the next weeks is fill in the work
I started in my proposal AtomAsRDF, that would allow Atom to be
seen as an RDF/XML document, though one constrained by an Relax-NG
syntax.
This will require a week or two of serious group
http://www.intertwingly.net/wiki/pie/PaceRepeatIdInDocument
Abstract
Explicitly state that multiple versions of the resource identified by a
particular atom:id may appear in the same document. Also, clarify
somewhat what the atom:id must be unique to.
Rationale
1. In order to show the revisio
> And even though many people seem to willing to create fill in language
> for that part of the spec to make it seem like this part has been
> addressed, your on the ground initial reaction is the correct one:
> there is no well defined extension mechanism.
Henry: I suspect that Bob's reaction wo
On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote:
>
> My preference would be something like
>
> This specification assigns no significance to the order of atom:entry
> elements within an Atom Feed Document. Atom Processors MAY present
> entries in any order, unless a
Have you had any more luck with this part of the mapping? Is this a
problem with the current Atom syntax if not?
Henry Story
On 28 Jan 2005, at 22:27, David Powell wrote:
I think it
handles everything except for xml:lang - I'm not sure what's happening
with xml:lang at the moment - but it should b
On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman <[EMAIL PROTECTED]> wrote:
> >> Ordering of the element children of atom:feed element MUST NOT be
> >> considered significant.
+1.
I accept there are cases where it might be useful to associate
significance to document order, such as 'Top 10' . But I
I don't have that much of an opinion now on the head in entry and
various
other proposals.
But I do find your comment that moving something off to an extension
essentially kills it to be a very important remark. This is clearly
to say that Atom has not yet dealt with the extension part of the
ch
On 5 Feb 2005, at 11:20, David Powell wrote:
This specification assigns no significance to the order of atom:entry
elements within an Atom Feed Document. Atom Processors MAY present
entries in any order, unless a specific ordering is required by an
extension.
Given a model of only informative metad
On Sat, 5 Feb 2005 01:41:24 -0600, Roger B. <[EMAIL PROTECTED]> wrote:
>
> > Any feedback on this guys? Curious to see what type of interest there is
> > here...
>
> Kevin: Why would anyone want to fiddle around with HTML classes to
> indicate comments when they can just publish/consume commen
>(I.e., I could come up with the UseLexicalOrdering extension, and
>require processors to understand it to use the feed, assuming our
>extensibility model supports that, which I very much hope it will).
Ok, well I am assuming that we wont have MustUnderstand extensions, therefore
Having started agreeing with the initial post, and having read more of
the
thread I am now divided about what the best position is.
In some sense the order is of the entries should not matter. All the
important
data to order the entries is in the entries themselves given by the
modified date,
t
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 conta
On 5/2/05 12:14 PM, "Graham" <[EMAIL PROTECTED]> wrote:
>> {{{ This specification assigns no significance to the order of
>> atom:entry elements within the feed. Processors MAY present entries in
>> a different order to which they are appear in an Atom Feed Document.
>> }}}
>
> First sentence no
> But if three are added, you can't order those three.
Walter: I dunno... seems to me, if the publisher hasn't included
atom:published info, then it's probably safe to assume that the order
of those entries isn't important.
--
Roger Benningfield
JournURL
86 matches
Mail list logo
