I don't see where the consensus was by the way. And I never saw any
vote on the
issue. Like most issues one gets the impression that Atom is run on
some pretense
democracy. Some people have made up their minds for god knows what
reason, and others
are just here to follow. The more we chatter on
Henry Story wrote:
So I call for a real open vote on the issue.
You don't need to call for a vote, just ask the chairs/editors who keep
track of such matters, about the particular specification.
If you can point out to me my recollection of the consensus on that
issue is incorrect, then do so.
On 19 Apr 2005, at 18:27, Bill de hÓra wrote:
Henry Story wrote:
So I call for a real open vote on the issue.
You don't need to call for a vote, just ask the chairs/editors who
keep track of such matters, about the particular specification.
Well we need some objective way to tell what the
Henry Story wrote:
I don't see where the consensus was by the way. And I never saw any
vote on the issue. Like most issues one gets the impression that Atom
is run on some pretense democracy.
There is no voting in the IETF. Please read the beginners' documentation
found on ietf.org. Here's a
I'm in favour of allowing duplicate ids when the source-id is different
to simplify creating merged feeds, which would allow the client to
figure out what to do. Under any other circumstance, definitely not.
Graham
Ok. I am sorry. I thought I had made a really good case for a simple
argument to allow
multiple entries with the same id in a feed, and thought it had in fact
made it into the spec.
I then discovered that it still had not.
I cleazrly just have no idea how one goes around convincing this group
Just to end on a positive note, I'll +1 this suggestion by Graham.
Henry
On 19 Apr 2005, at 18:30, Graham wrote:
I'm in favour of allowing duplicate ids when the source-id is
different to simplify creating merged feeds, which would allow the
client to figure out what to do. Under any other
Graham wrote:
I'm in favour of allowing duplicate ids when the source-id is different
+1
This is essentially what I was trying to get at with the horribly
tortured language that I recently proposed. Clearly, I support Graham's
suggestion and hope that someone with better skill at
