Re: Proposal: rel="payment"

> I really don't buy this argument.  I've read the proposal. I would not
> expect any commercial aggregator to support the feature unless there
> is a way for them to get paid - and I do not see that.

Wrong. FireANT (the aggregator I am helping develop) will support.
Web based aggregators like MeFeedia, 49Media, and RSSBazaar are
already supporting. Yahoo! and FeedBurner have already pledged
support.

> The right way to do this in my view is for the resource link to manage
> any payment/permission requirement or the resource itself to offer
> an opportunity to donate.

I don't quite understand what you're saying? What are you terming as
the "resource link"?

> I understand what you are trying to do but I would not expect it to
> prove useful or be widely adopted.  I really doubt that anyone would
> use the mechanism at the feed navigation level.

Ummm, look how many bloggers use tip jars. What about fundraising
campaigns for politics and social causes? How about product reviews
and affilliate links? Cafe Press shops? All these ways to get paid are
already widely used. Why not make those relationships explicit in the
feed and in the HTML?

-josh


On 7/31/05, Steven Ericsson-Zenith <[email protected]> wrote:
> 
> I really don't buy this argument.  I've read the proposal. I would not
> expect any commercial aggregator to support the feature unless there
> is a way for them to get paid - and I do not see that.
> 
> The right way to do this in my view is for the resource link to manage
> any payment/permission requirement or the resource itself to offer
> an opportunity to donate.
> 
> I understand what you are trying to do but I would not expect it to
> prove useful or be widely adopted.  I really doubt that anyone would
> use the mechanism at the feed navigation level.
> 
> With respect,
> 
> Steven
> 
> 
> Joshua Kinberg wrote ..
> > rel="payment" does not entail payment as restriction to access.
> > It simplly defines a location where some form of payment is accepted.
> > This is completely open ended... it could be an affillliate link as
> > described previously, a tip jar link, a link to donate to some other
> > cause such as a "Tsunami Relief Fund," etc...
> >
> > By explicitly defining a payment link in this way, aggregators can
> > display a custom payment button that points to the payment location.
> >
> > As with any microformat, this simply makes implicit relationships more
> > explicit.
> >
> > See a more detailed proposal on the format here:
> > http://videovertigo.org/information/relpayment/
> >
> > See the original conception of the format here (with video):
> > http://www.momentshowing.net/momentshowing/2005/07/video_relpaymen.html
> >
> > Here's further explanation from Peter Van Dijk, creator of the
> > videoblog aggregator MeFeedia, on how MeFeedia supports rel="payment":
> > http://poorbuthappy.com/ease/archives/2005/07/18/2767/
> >
> > And here is a more detailed technical spec on the HTML syntax for rel="payment":
> > http://videovertigo.org/wiki/index.php/RelPayment
> >
> >
> > -Josh
> >
> >
> > On 7/31/05, Steven Ericsson-Zenith <[email protected]> wrote:
> > >
> > > I have to say that I am a little confused by this proposasl and this
> > > use case.  So let me ask the obvious question:
> > >
> > > Why wouldn't the link to the "commodity described" simply take care
> > > of this?  After-all, one assumes you would have to check for the
> > > payment/permission to access in anycase.
> > >
> > > I see no reason whatsoever, for this property - have I missed
> > > something?
> > >
> > > With respect,
> > >
> > > Steven
> > >
> > >
> > >
> > > [email protected] wrote ..
> > > > Joshua Kinberg <[email protected]> wrote:
> > > >
> > > > > > What do you think of the application of rel="payment" to a feed
> > like
> > > > > > mine (where the rel="payment" link goes to a purchase page for
> > the
> > > > > > commodity described by the feed entry)?
> > > > >
> > > > > This is exactly one of the use cases we had in mind
> > > >
> > > > OK, that's good.
> > > >
> > > > [snip]
> > > >
> > > > > Now... a more technical question: It seems that it would be silly
> > to
> > > > > limit the use of the rel="payment" element to one per RSS item. As
> > an
> > > > > example, I might compare several products in a blog entry and wish
> > to
> > > > > include payment links for all of them. So how should an aggregator
> > > > > deal with the existence of multiple payment links?
> > > >
> > > > It should display them all, no?
> > > >
> > > > The real question is whether it's legal to have multiple <atom:link>
> > > > elements with the same relation, media type and language.  From a quick
> > > > look at the most recent draft, I see nothing forbidding it.
> > > >
> > > > Ideally, if there were more than one, you'd want to be able to give
> > each
> > > > rel="payment" link a title attribute, say (or string content to be
> > > > interpreted as a title).  I'm not sure if either of those are legal
> > for
> > > > an extension, but I'm no expert here.
> > > >
> > > > Regards,
> > > >
> > > > Peter
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
>


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/