* David Powell <[EMAIL PROTECTED]> [2006-04-27 12:10]:
> Aristotle's suggestion is ok, in that it saves a bit of typing
> in the common case where there is only one link - but in the
> case where there is more than one link, a combined count seems
> pretty useless: if there are multiple comment li
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
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. Publishe
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"?
* James M Snell <[EMAIL PROTECTED]> [2006-04-22 03:05]:
> ... 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 [1]
... 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 what's c
* 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 w
> 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 ar
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 eli
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
* 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/R
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
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 Draf
Thursday, April 13, 2006, 8:24:48 AM, Thomas Broyer wrote:
>> c. Create a new replies extension element
>>> type="..."
>> hreflang="..."
>> title="..."
>> count="..."
>> when="..." />
> -0.5, it *is* a link
thr
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, 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 wi
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
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 ext
* 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
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
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,
* 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` an
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 al
Works for me. I couldn't think of a better way to describe the concern
than what Mark included in his draft so I simply copied it verbatim.
Mark N: I hope you don't mind. :-)
- James
James Holderness wrote:
>
> James M Snell wrote:
>>> Not a proofreading issue, but shouldn't section 5 say som
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 dif
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
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 b
28 matches
Mail list logo
