> Alternatively, you could decide to
> trust that the feed publisher may have already done all this work and
> has provided a reasonably accurate count in the form of the thr:count
> attribute. It's your choice.
This to me is what its all about. I hear a lot of people saying that you
can't be su
me that it could change - and
in fact it did. We implemented it knowing full well it wasn't final. But
despite the risk of it not being final - it was still the best solution
on the market.
Byrne Reese
Manager, Platform Technology
Six Apart, Ltd.
Speaking up:
http://www.majordojo.com/atom/standardizing_the_atom_thread_extension.ph
p
No surprise I guess, but I am a huge +1. Lock this spec down and ship
it.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
Sent: Monday, May 15, 2006 3:
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
> * Reconstructing a feed should use:
> a) a specific relation, e.g., "prev-archive"
-1
> b) a generic relation, e.g., "previous"
+1
This is a topic that has come up recently in conversations here at Six
Apart that I thought I would share with a broader community to hear your
feedback and thoughts on the subject:
We see a value in representing the following attributes about an author:
* their Display Name (e.g. "Byrne
+1 to James' +1 of Eric's -1.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
> Sent: Monday, October 24, 2005 8:13 PM
> To: Eric Scheid
> Cc: Atom Syntax
> Subject: Re: Sponsored Links and other link extensions
>
>
> Eric Scheid w
Any chance this specification could be extended to contain meta data
about the replies? Specifically, how many replies that may exist for a
given entry?
I would love a mechanism to be able to recreate:
--- cut here ---
POST TITLE
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Donec
lso it is
sufficiently specific and sufficiently open ended to give me (the
implementer) a very reasonable set of ways to apply the principal.
Byrne Reese
> >Second, although less important - even applications which do support
> >rel="subscribe" will have to implement a fallback behaviour.
> Arguably,
> >they already do in some fashion, because a feed may omit the
> rel="self"
> >link, so I don't know if this is such a pressing issue.
> >
> >Fo
+1 to all.
Wh!
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham
> Sent: Thursday, October 20, 2005 4:53 PM
> To: Atom Syntax
> Subject: New Link Relations -- Ready to go?
>
>
> At this point, I believe the following represent
> > 1. Which relationship, next or prev, is used to specify a link
> > backwards in time to an older archive. Mark Nottingham's
> Feed History proposal used prev.
> > Mark Pilgrim's XML.com article used next.
>
> I'd prefer that our use of 'prev' and 'next' be consistent
> with other uses els
> I think that defining the terms well and in relation to the
> subscription feed will help; after all, the terms don't surface in
> UIs, so it should be transparent.
+1
Maybe this goes without saying, but I think the spec needs to either:
a) define these terms clearly and how they should b
+1
The meaning of these terms depends so much upon the feed it is being
used within. That and your own mental model.
If you visualize a feed like this:
---
|
|
|
|
|
|
|
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Nottingham
Sent: Friday
If only to make the nature of a feed, or state of a feed more
deterministic and less ambiguous...?
Nottingham's Feed History achieves this objective for me. I *knew* I had
read something about this somewhere. :)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Beha
+1
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
Sent: Sunday, October 09, 2005 9:06 PM
To: James Holderness
Cc: Syntax Atom
Subject: Re: Feed History -04
I've been considering asking the Opensearch folks if they would be
willing to sep
differentiate between the two types of feedback an entry may receive. Does anyone know of a way to achieve that?
Byrne Reese
Manager, Platform Technology
http://www.sixapart.com/pronet/
of that entry.
Is there an existing mechanism for this anywhere? An
extension perhaps?
Byrne Reese
Manager, Platform Technology
http://www.sixapart.com/pronet/
I was wondering if someone might be able to summarize the issues
associated with a and ? What were
the primary objections?
I ask because it seems like a very logical core component for the spec,
especially as a link relation.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PRO
t me, or is that kind of vague?
Or to ask a more leading question, can the scheme element be
used to differentiate between a “category” and a “tag?”
And if so, how?
Byrne Reese
Manager, Platform Technology
http://www.sixapart.com/pronet/
20 matches
Mail list logo
