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.

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

<*> 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/