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 the
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
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,
(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
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
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
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
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
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 would
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
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
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
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 about
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
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.
* 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.
+1.
+1 - I don't
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,
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
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
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
-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
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
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
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
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
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
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 focus
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
/ 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:
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 Thing
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
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
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
/ 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 is
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
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
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
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
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
Graham wrote:
#pragma section-numbers off
== Abstract ==
Clarify when not to update atom:updated
+1
cheers
Bill
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
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 06:25 PM, Antone Roundy wrote:
I'd be perfectly happy with not allowing atom:id to be repeated in a
feed or the hypothetical aggregation if we had an archive
element which acts exactly like aggregation except that atom:id may
be repeated.
Oops, correction:
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 feed or the hypothetical aggregation if we had an
archive element which acts exactly like aggregation except that
atom:id
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
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 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:updated
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.
where
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 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 metadata
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 are:
*
consider
link href=tag:example.com,2005:/2005/02/musings /
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
feed
[...]
entry
Hmm.. I'm sorry but this just seems wierd to me.
archive
head.../head
feed
entry
idid:version1/id
/entry
/feed
feed
entry
idid:version2/id
/entry
/feed
feed
entry
idid:version3/id
/entry
/feed
/archive
What is the point of having the feed
-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
54 matches
Mail list logo
