Saturday, April 22, 2006, 1:53:26 AM, James M Snell wrote:
So this is what I've got:
count = element thr:count {
attribute xml:base { atomUri }?,
attribute ref { atomUri }?,
attribute updated { date-time }?,
( nonNegativeInteger )
}
I think that is ok.
Aristotle's
That, or You lied to me when you told me this was a web feed!
(credit: 'href (http://plasmasturm.org/code/))
A friend of mine in a compiler writing class produced a compiler with
one error message 'you lied to me when you told me this was a
program'.
– Pete Fenelon
On 4/21/06, James M Snell
Returning from the beyond to cast a vote.
James M Snell wrote:
a. Status quo. Leave things the way they are in the current draft
+1
b. Drop thr:count and thr:when from the spec.
-1
I have yet to hear personally an argument compelling to me to believe
why these elements should be
James M Snell wrote:
Maybe, but given that WG messed up in not making the link element
formally extensible, it's not likely to be pretty.
Nice one.
a. Status quo. Leave things the way they are in the current draft.
-1.
James M Snell wrote:
None of the implementors I'm aware of are
* James M Snell [EMAIL PROTECTED] [2006-04-13 09:05]:
Maybe, but given that WG messed up in not making the link
element formally extensible, it's not likely to be pretty.
Yes. WGs mess up. It’s just life. In a perfect world, this would
be different, but Atom took long enough to ship. What we
grumble ... I'm not really happy with it but this would work.
To be absolutely honest, David's comments here [1] really got me
thinking. It's definitely worth a read and alone was sufficient to sway
me on this. I don't like it; the use of the supplemental element is
ugly, but it's better than
* James M Snell [EMAIL PROTECTED] [2006-04-22 03:05]:
grumble ... I'm not really happy with it but this would work.
That’s roughly how I feel about it. :-)
It has in fact been the theme all throughout the Thread extension
development discussion…
To be absolutely honest, David's comments here
On 22/4/06 10:53 AM, James M Snell [EMAIL PROTECTED] wrote:
Where that gets nasty, of course, is when the href
is relative and xml:base is being used to set the Base URI. Publisher
would need to make sure that the href/ref combo match up properly
Would this be considered a match?
link
The feedvalidator really does need a ValidButPositivelyIdiotic warning.
- James
Eric Scheid wrote:
On 22/4/06 10:53 AM, James M Snell [EMAIL PROTECTED] wrote:
Where that gets nasty, of course, is when the href
is relative and xml:base is being used to set the Base URI. Publisher
would
James M Snell wrote:
a. Status quo. Leave things the way they are in the current draft
+1
b. Drop thr:count and thr:when from the spec.
+0.5
c. Create a new replies extension element
-1
d. Create a supplemental extension element
+0
A. Pagaltzis wrote:
[snip]
Maybe we can think of other ways to expose this information so
that it fits the Atom extension model? Are those attributes
really the only possible approach to this issue?
Regards,
Maybe, but given that WG messed up in not making the link element
formally
On 13/4/06 8:02 AM, David Powell [EMAIL PROTECTED] wrote:
In terms of the considerations to the interoperability of running
code, thr:replies seems to beat atom:link in every way. It even
manages to be more concise (you don't need the @rel), and you wouldn't
need to put thr:count and
Thursday, April 13, 2006, 6:11:32 AM, Eric Scheid wrote:
atom:link beats thr:replies on the basis that I don't need to understand
what replies are to discover that there is a link from this thing to that
thing.
atom processors know what atom:link is, but it wouldn't know what to do with
David Powell wrote:
But what would processors do with an atom:link? Atom Protocol uses
edit, there have been calls for a stylesheet. Links aren't
necessarily things that you'd display to users (check HTML out for
examples of that: favicon, P3P, Atom/RSS, GRDDL)
Well if you've got a decent
Thursday, April 13, 2006, 8:24:48 AM, Thomas Broyer wrote:
c. Create a new replies extension element
thr:replies href=...
type=...
hreflang=...
title=...
count=...
when=... /
-0.5, it *is* a link
See below...
http://www.kirit.com/
-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-atom-
[EMAIL PROTECTED] On Behalf Of David Powell
Sent: Thursday, April 13, 2006 4:49 PM
To: Thomas Broyer
Cc: Atom-Syntax
Subject: Re: Feed Thread Draft Updated
I'm bothered about
On 13/4/06 6:59 PM, David Powell [EMAIL PROTECTED] wrote:
But what would processors do with an atom:link? Atom Protocol uses
edit, there have been calls for a stylesheet. Links aren't
necessarily things that you'd display to users (check HTML out for
examples of that: favicon, P3P, Atom/RSS,
* David Powell [EMAIL PROTECTED] [2006-04-13 11:10]:
But what would processors do with an atom:link? Atom Protocol
uses edit, there have been calls for a stylesheet. Links
aren't necessarily things that you'd display to users (check
HTML out for examples of that: favicon, P3P, Atom/RSS,
Tuesday, April 11, 2006, 9:20:32 PM, James M Snell wrote:
I also added a new warning for implementors: Implementors should note
that while the Atom Syndication Format does not forbid the inclusion of
namespaced extension attributes on the Atom link element, neither does
is explicitly allow
* David Powell [EMAIL PROTECTED] [2006-04-13 00:15]:
This seems to be the wrong priority to me.
Convincing arguments, IMHO; +1.
James:
As regards Robert’s vociferous comments, you have to acknowledge
that while the rest of the draft was hashed out in several
iterations, these `thr:count` and
Hey Folks,Great discussion going on here... Thanks! http://www.oreillynet.com/xml/blog/2006/04/the_power_of_the_people.html
On 4/12/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
* David Powell [EMAIL PROTECTED] [2006-04-13 00:15]: This seems to be the wrong priority to me.Convincing arguments, IMHO;
A. Pagaltzis wrote:
* David Powell [EMAIL PROTECTED] [2006-04-13 00:15]:
This seems to be the wrong priority to me.
Convincing arguments, IMHO; +1.
Sorry, not convinced. I never once claimed that the motivation for
using link was because it looked better. What I did claim was that
* James M Snell [EMAIL PROTECTED] [2006-04-13 04:10]:
What I did claim was that there is little to no technical
justification for exactly duplicating the link element for the
sole purpose of introducing two new optional attributes...
David countered that having this information is clearly
The Feed Thread draft has been updated.
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-07.txt
Among various editorial changes, the in-reply-to id attribute is now
called ref.
I also added a new warning for implementors: Implementors should note
that while the Atom
James M Snell wrote:
The Feed Thread draft has been updated.
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-07.txt
I am an absolutely terrible proofreader so I'd really appreciate it if
someone could do a quick scan over the current doc to find the typos
that I know must
James Holderness wrote:
[snip]
Section 4, paragraph 1:
into a separate feed document (singular document)
its value is assumed (no apostrophe)
Section 4, last paragraph:
neither does it explicitly allow (is - it)
Section 6:
Security considerations: (see section 5) (6 - 5)
Fixed in
James M Snell wrote:
Not a proofreading issue, but shouldn't section 5 say something about
DOS attacks using replies links to third party servers? I wouldn't be
surprised if some clients automatically subscribed to all replies links
in a feed even if they were 100MB zip files on a completely
27 matches
Mail list logo
