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
Bill de hÓra wrote:
I'm going to think about it some more but atm I'm not sure what you're
proposing helps against DOS.
My proposal says that things are considered the same only if found
in the same feed. This is, I believe, the only way to prevent someone from
maliciously erasing
It may be too late, but either way, I'd like to get this into concrete
form. Does anyone think this is worse than requiring the xhtml:div?
Better?
http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper
== Abstract ==
Replace the requirement for an xhtml:div wrapper for
Robert Sayre wrote:
All,
HTML:
http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html
diffs:
http://atompub.org/2005/04/18/draft-ietf-atompub-format-08-from-7.diff.html
I was about to ask for the html, thanks :)
cheers
Bill
Antone Roundy wrote:
It may be too late, but either way, I'd like to get this into concrete
form. Does anyone think this is worse than requiring the xhtml:div?
Better?
http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper
Definitely better!
+1 for me
--
Thomas Broyer
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
Is the Relax NG schema from the appendix hosted as a standalone HTTP
resource somewhere on atompub.org ?
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
Henri Sivonen wrote:
Is the Relax NG schema from the appendix hosted as a standalone HTTP
resource somewhere on atompub.org ?
Now it is.
http://atompub.org/2005/04/18/atom.rnc
Robert Sayre
I don't see the point of this. The problem Sam discussed can be solved
without it and without requiring the div. Death to the div is not part
of the content.
i) Encourage xhtml users to wrap content in a div
ii) Require that they before adding any wrapper, they check whether
there already is
I believe we decided not to address licensing in the Atom core because
the probability of not getting it quite right is too high, especially
given the differences between laws in various jurisdictions around the
world. Having something in the core might require consuming
applications to
The problem I'm having is with LiveJournal. They have 6.8 million
registered users, with 2.7 million active. We're talking about a
robots.txt of hundreds of megabytes. I imagine other blog hosting sites
(Blogger, Xanga) have a similar problem.
Also, robots.txt can only handle noindex. What about
Regarding the privacy facet: True privacy probably requires access
control, which requires authentication. In fact this is one of the
major use cases for authenticated Atom feeds in AOL Journals.
-John
Nikolas 'Atrus' Coukouma wrote on 4/19/05, 8:50 PM:
Some pertinent quotes from the
James Robertson wrote:
At 11:38 PM 4/19/2005, you wrote:
The problem I'm having is with LiveJournal. They have 6.8 million
registered users, with 2.7 million active. We're talking about a
robots.txt of hundreds of megabytes. I imagine other blog hosting sites
(Blogger, Xanga) have a
19 matches
Mail list logo
