Tuesday, May 29, 2007

Is FB F'd Up?

VecoSys has the following piece: (but the Digg Army killed the site).


I've been waiting for the Googleplex to move its lever from Good to Evil. Meanwhile, Facebook has picked up the pace. This is the dark side of API development. Use their data for free. Use their data in a smart way and they'll steal your idea (or would that be 'use your code for $0'?).

Facebook launched their Developer API last week to a lot of acclaim. Several commentators jumped in with the hyperbole, claiming that this platform, with its 20 million, and growing, users, would be a fine space in which to build a business. Much was made of comments at the launch that this was a free and open API - there would be no restrictions on what use developers could make of this service. Techcrunch says MySpace v. Facebook: “It’s Not A Decision. It’s an IQ Test”

Facebook is viewing things from exactly the opposite position: they are giving startups access to Facebook’s core feature set, and allowing them to show advertising and conduct transactions with users without even asking for a cut.

and Josh Kopelman at Redeye VC asks Myspace - the next Prodigy?

Myspace also has a policy against commercial activity in widgets, including placing advertising in a widget – leading some to wonder whether Myspace would ultimately erect a “tollbooth” for the widget providers.

I wasn’t at the launch, so I don’t know whether this was actually said, cleverly implied (spun) or whether it was a product of the fevered imaginations of those who want this to succeed (is Facebook the Apple of the Social Networking space against the Microsoft of MySpace?). However, prompted by Marc Canter, I decided to track down the Terms and Conditions of the Facebook Developers Platform and take a look at what was in there.
Be aware, I am in no way a lawyer, and generally I don’t have that much interest in the ins and outs of terms and conditions. Everything that follows is my own view from a fairly quick reading. I’d also state that I don’t think there is anything in here that is particularly onerous or strange. But, even a quick reading gives the lie to the idea that developers have free access to this platform and that the situation is so much better than in MySpace. While this platform at least codifies access for developers, the basis on which successful applications will be allowed to continue access is totally unclear. Be warned, but not too afraid.

Be aware of this:
1. Facebook can limit you or terminate you at any time at their sole discretion (Section A.3)
2. Facebook reserve the right to impose fees at time and in any manner (Section 3)
3. Facebook can copy and distribute your Application, and analyse the content in order to target advertising (Section 4)
4. Facebook may create similar applications to yours, with no obligation to you (Sectition 4)
5. You can’t use any name or domain name address containing ‘facebook’, even at the third level, eg.g “facebook.xxx.com” (Section 6. C)
6. Be careful what ID you use for your developer account - IDs can’t be transferred or sold on, but nor do there seem to be corporate IDs. (Section 7)
7. Facebook can change the Terms and Conditions at any time, your only recourse if you don’t like this is to STOP USING THE SERVICE
(all sections below)

Now, some of this is trivial and some off it is not - but there is no solid ground here. Will Facebook impose a ‘tollbooth’ or tax on successful widgets? Sure looks like they want to. Will they be building their own competitive versions? Sure looks like they want to. Can they cut you off from the platform at any time? Sure looks like they can. Can they change the ground on which you operate? Sure looks like they can. Do you have a hard and fast relationship with this platform, making it safe to build a 20 million user widget based company on? I don’t think so.
I would say that Facebook have looked at MySpace and learned a lesson : there are a lot of developers at the gates. They have built a platform that seems to bopen up their aworld in an exciting way. But they retain their fingers on the levers of power and they willl exercise those levers as mercilessly as My Space when the time comes. That is their right, and the correct course of action. I just don’t think we should believe the free access hype at this point.

Developer Terms of Service

A.3) As provided in the Facebook Platform Documentation, your Facebook Platform Applications may make Calls at any time that the Facebook Platform is available. We may at any time, and over any given period of time, limit the number of Calls any Facebook Platform Application may send to the Facebook Platform, or prohibit any Facebook Platform Application from sending Calls to the Facebook Platform, as we deem appropriate in our sole discretion;

Section 3. Fees We reserve the right to charge a fee for using the Facebook Platform and/or any individual features thereof at any time in our sole discretion. If we do charge a fee for using the Facebook Platform or any feature thereof you do not have any obligation to continue to use the Facebook Platform or the applicable feature. However, if you do: (i) we reserve the right to specify the manner in which the fee will be calculated, the terms on which you will be invoiced and charged and the terms of payment; and (ii) any and all fees payable by you pursuant to this Agreement are expressed exclusive of all taxes and duties, including Value Added Tax (”VAT”) or any similar applicable sales tax. In addition to such fees payable, you will pay any sales, use, value-added or import taxes, customs duties or similar taxes that may be assessed by any state and/or jurisdiction (collectively, “Taxes”) that Facebook is legally required to charge on the applicable fees under this Agreement. If requested to do so by Facebook, or as otherwise required by applicable law, you will supply your VAT identification number to Facebook. We may also change the fees or fee structure for the Facebook Platform or any feature thereof at any time in our sole discretion, and in such event your continued use of the Facebook Platform or such feature constitutes your agreement to such change (provided, that you will not have any obligation to continue to use the Facebook Platform or such feature).

Section 4. By accessing the Facebook Platform, or submitting any Facebook Platform Application to us to be hosted by us, you are directing us to store copies of that Facebook Platform Application (if applicable) and any and all Developer Provided Content provided through any Facebook Platform Application on our servers. You hereby grant us a worldwide, perpetual, irrevocable, non-exclusive right and license, with the right to sublicense, to: (a) access, reproduce, display, distribute, perform, and store on our servers your Facebook Platform Application and any Developer Provided Content, and to create derivative works of Developer Provided Content, as may be necessary or desirable to make such Facebook Platform Application and Developer Provided Content available to Facebook Users in accordance with the terms of this Agreement and the Facebook Platform Documentation and the Facebook Platform Application Guidelines; and (b) otherwise access, use and analyze any Developer Provided Content for our internal business purposes (e.g., for the purposes of targeting delivery of advertisements or other content to persons who have viewed particular types of Developer Provided Content). You understand and agree that Developer Provided Content that is displayed on the Facebook Site may continue to appear on the Facebook Site, even after you have terminated access to your Facebook Platform Application or terminated this Agreement, as such Developer Provided Content may have been incorporated into user profiles, news feeds or other features, and that such usage may continue indefinitely.


Section 4.
You understand and acknowledge that Facebook may be independently creating Applications, content and other products or services that may be similar to your Facebook Platform Applications and Developer Provided Content, and nothing in this Agreement will be construed as restricting or preventing Facebook from creating and fully exploiting such Applications, content and other items, without any obligation to you.

Section 6.C. The foregoing prohibition includes, without limitation, using any registered or unregistered trademark, service mark, trade name, logo, trade dress or other business identifier of Facebook (e.g. FACEBOOK or FBOOK) or any third parties that advertise on the Facebook Site, or variations or misspellings of any of them, in the name of an Application or in a URL to the left of the top-level domain name (e.g., “.com”, “.net”, “.uk”, etc.) — for example, URLs such as “facebook.xxx.com”, “faacebook.com “, “facexxx.com” or “facebookprofiles.net” are expressly prohibited.


Section 7. If you are an individual acting as a representative of a corporation or other legal entity that wishes to use the Facebook Platform, then your individual Facebook Site account, or that of another employee of such entity will be deemed to satisfy this requirement. Facebook Platform accounts are associated with one or more public key/private key pairs, which you must use to access the Facebook Platform. Examples include a Facebook-issued Access Key ID string (as a public key) and a Facebook-issued Secret Access Key string (as a private key). When you complete the account creation process, you will be issued unique account identifiers, and may add a public key to your account. Account identifiers (i) identify your account and (ii) allow your Facebook Platform Applications to make Calls to the Facebook Platform. Account identifiers are immutable and will always uniquely identify your Facebook Platform account. Public key/private key pairs are unique to your account and are subject to change. Private keys are for your personal use only and you may not sell, transfer, lease, distribute, sublicense or otherwise disclose your private key to any other party.

Section 14. We may modify any of the terms and conditions contained in this Agreement, at any time and in our sole discretion, by posting a change notice or a new agreement on the Facebook Site. IF ANY MODIFICATION IS UNACCEPTABLE TO YOU, YOUR ONLY RECOURSE IS TO STOP USING THE FACEBOOK PLATFORM. YOUR CONTINUED USE OF THE FACEBOOK PLATFORM FOLLOWING OUR POSTING OF A CHANGE NOTICE OR NEW AGREEMENT ON OUR SITE WILL CONSTITUTE YOUR BINDING ACCEPTANCE OF THE CHANGE.


Sunday, May 27, 2007

You Don't Talk. You Gibber

I have been a lurker on the RSS Public list an email offshoot of the "RSS Advisory Board:" A bunch of self-appointed developers? Key developers for RSS? People with too much time on their hands? You decide. I haven't gotten involved, because of the "ain't broke don't fix" concept. RSS 2.0 works better than RSS 0.92-- I have used both alot. I followed the list because it was entirely likely that the RSS community would creep up on the ball as it lay on the green-- one put from victory and pound it with a line drive. It's always good to keep an eye on the ball-- even as it sails into the wilderness.
Dave Winer is sometimes credited as inventing RSS, or adapting his Userland model to use the Netscape model-- or whatever. It can be exhausting picking apart who invented, who exploited, who just stole the glory. Somehow "Really Simple Syndication" has become anything but. The flurry of elements and attributes being nudged into the spec or debated or tossed is amazing. At the end of the day, it's a mark-up language. The horsepower comes from the applications that interpret the XML and make it into something useable. Instead, there is a pissing match over control, legitimacy and the complexities of the spec (see below and here). If you want to see the RSS RFC, good luck. This is as close as it gets: http://cyber.law.harvard.edu/rss/rss.html. The lack of an RFC and the lack of solidarity freaks me out. It's like going in for heart surgery and your surgeon leans over you to offer you some reassurance. You say, "Doctor: I'm scared." He replies, "Doctor? Who said I was a doctor?"
If anyone asks why Microsoft is a colossus and Linux a tremendous and well used miasm, this is why. The Open Source approach is frenetic but the chaos mires it. While Winer goes on about how many developers he will allow to dance on the head of the pin, Microsoft developers are polishing their applications to use their interpretion of RSS. No matter how abhorrant the spec, when Micorosof uses it, it becomes the defacto standard. Trust me: before Microsoft got into the HTML game,
tags were a nice mistake-- try to find a Web 2.0 site that doesn't have them, now.

Here is the long and drawn out exchange. Is it over yet? Not likely.
Dave Winer to rss-public

I spent some time reading and thinking before responding, and have an
idea.

There are just a few people who are dug in on positions that actually
are quite close, and the majority of people are not dug in, and want
to help the syndication community do better work. I'm not saying that
the people who are dug in don't want the same thing.

First, please Sam Ruby, stop casting everything I do, and others, in
such a negative light. We aren't so stupid, or conflicted, and it's
preventing discourse. I will not respond in the same manner to you, I
tune out when you do it. Just today you did it on your blog, in
trying to revive an old disagreement that you don't really understand.

Second, Rogers and Randy, you have to give up the belief that you're
running the same advisory board that existed before Rogers joined it.
That group never had the charter that you've assumed, and it stopped
functioning a long time before your attempt to revive it. Further, I
never envisioned that refinement work would be taking place on the RSS
2.0 spec almost five years after its publication. The goal was to
reserve a few *months* to debug it after it moved from the UserLand
server to the Harvard server, for link breakage, typos, and possible
catastrophic mistakes that needed correction (which thankfully,
never surfaced). You are way past the time for that kind of work. I
know you can find an exception, but that doesn't change my belief that
you can't be contemplating these kinds of changes this late in the
game, even if you were on the advisory board, and it continued to
exist, which I don't believe it does.

You keep asking me for answers, and I keep giving them to you, they're
just not the answers you want to hear. I've consistently been saying
"hands off" to your request that you or anyone else be permitted to
change the RSS 2.0 spec.

Third, if there are other people actively participating in the group
you're running, it would be helpful if you could ask them to
participate in this discussion and consider the things I'm asking you
to consider. I don't mean vote on it, I mean participate in the
discussion.

One of the things that really sparked my attention is Randy's advice
here a few days ago, where he said something about item order that is
absolutely not true. At that point I got an idea of how dangerous this
work you're doing actually is. With only two people actively working
on your board, and no real discussion taking place, you're going to
make serious mistakes. You can do that if you're working off on the
side, but to the extent that people believe that you're working on the
real spec, well, you can see how scary that is.

Now, if we can get your group to do two things, I will offer a
compromise of my own.

I will join as a member, if you want me to, to help give it
legitimacy. At that point these time-wasting discussions can end. I
would also suggest that you offer Sam Ruby a position, esp if he takes
the first item here to heart.

The two things:

1. Recognize that the RSS 2.0 spec is on the Harvard server, and it is
not going to change.

2. Change the mission of this group to working on a profile. Let's
come up with a memorable name for the profile that doesn't sound
official or mandatory, and let's get to work on solving problems, and
then promoting the result to the users.

If there are pragmatic reasons why you can't do these things, I'd like
to know what they are.

And please give this some thought before you reject it, or argue
against it. Think about what you want to do with your time, work on
technology and help the community, or argue about your right to do it.

Sincerely,

Dave Winer

-----------------------------------------------------------------------


Randy Morin to rss-public

May 26 (17 hours ago)


Dave,
If I said something absolutely untrue, then why don't you reply to that
comment and tell us what the truth is. That's the dangerous part. You
keep telling people they don't know RSS, but you never tell us what we
don't know about RSS. You state, "You keep asking me for answers, and I
keep giving them to you." I state, "No you don't, case in point."

If you go back to that comment and reply as to what I said wrong, then
I'll consider your compromise, which looks interesting.
Thanks,

Randy Charles Morin
http://www.therssweblog.com/

--- In rss-public@yahoogroups.com, "Dave Winer" wrote:
> One of the things that really sparked my attention is Randy's advice
> here a few days ago, where he said something about item order that is
> absolutely not true. At that point I got an idea of how dangerous this
> work you're doing actually is.

-----------------------------------------------------------------------

Mark Woodman to rss-public

May 26 (12 hours ago)

I think this is a great proposal by Dave. We've been asking for
clarifications on some of these things for years, and now he's offering a
way for us to get them. The board has to be willing to step away from the
notion of revising the spec, but a non-mandatory profile with Dave's name on
it will be taken as gospel anyway. (I hope Sam will join as well.)
-----------------------------------------------------------------------

Sam Ruby to rss-public

1:58 am (8 hours ago)

Mark Woodman wrote:
> I think this is a great proposal by Dave. We've been asking for
> clarifications on some of these things for years, and now he's offering a
> way for us to get them. The board has to be willing to step away from the
> notion of revising the spec, but a non-mandatory profile with Dave's name on
> it will be taken as gospel anyway. (I hope Sam will join as well.)

The nearest IETF equivalent to the RSS-Profile is a document called a
"Best Current Practice". By virtue of its name, it is not a gospel.
For starters, it is not eternal. In any case, neither Dave nor me
joining the board will cause WordPress to suddenly stop putting
entity-encoded HTML in RSS 2.0 titles, nor will it stop Snarfer from
having to deal with such feeds.

I see no harm, nor pressing need, in changing the the address of a
defunct mailing list to one that is active. I consider all the approved
changes in both branches of the RSS 2.0 spec after 11/11/02 to be of
this nature. I do, however, see considerable harm in revising the spec
for technical matters. I do see considerable harm in there being two
separate documents purporting to be "the" RSS 2.0 spec. Particularly if
one of them is open to consideration of revisions of a technical nature.

The very notion of a board is problematic. If it consists of people who
are chosen due to their active participation in the mailing list, that
can be made to work, but that does not appear to be the case here.
Whether or not I am considered a part of the board is not of grave
concern to me, in any case I have and will continue to participate in
discussions related to RSS, including on this very mailing list. What
is of significant concern to me is the inclusion of my name in a
document for which I neither approve of the process nor of the
conclusions reached.

I am not concerned about the occasional dispensing of bad advice by
members of this mailing list. This last time it was Randy. Next time
it might be me. Or perhaps someday it might be Dave himself. What does
concern me is the possibility that it might have gone unchallenged.
This again goes back to the point of a board consisting primarily of
people who don't actively participate.

Finally, offline technical discussions of the nature that Rogers
apparently doesn't want to disclose, is deadly.

- Sam Ruby

-----------------------------------------------------------------------

Alan Dean to rss-public

1:50 am (8 hours ago)

--- In rss-public@yahoogroups.com, "Dave Winer" wrote:
>
> The two things:
>
> 1. Recognize that the RSS 2.0 spec is on the Harvard server, and it is
> not going to change.
>
> 2. Change the mission of this group to working on a profile. Let's
> come up with a memorable name for the profile that doesn't sound
> official or mandatory, and let's get to work on solving problems, and
> then promoting the result to the users.

Dave,

I come to this discussion with no preconceptions and no bones to pick.
I *am* a professional developer, but I have not been active in the RSS
space. So my questions are entirely based upon general principles,
rather than the specific case. If I therefore misunderstand, I beg
your indulgence.

Q. Why should the spec be immutable? Specs *do* change. HTML does, for
example. From a general viewpoint, the best practice is to ensure that
changes are backwards-compatible, rather than preventing any change.
You are quite forthright on this point and I therefore imagine that
you have a darn good underlying reason for this position. Could you
share that reason with the list?

Q. What do you mean by by 'profile'? Does this refer to deeper
explanatory text?

Regards,
Alan Dean
http://thoughtpad.net/alan-dean

-----------------------------------------------------------------------

rcade to rss-public

5:41 am (4 hours ago)


--- In rss-public@yahoogroups.com, Sam Ruby wrote:
> I am not concerned about the occasional dispensing of bad advice by
> members of this mailing list. This last time it was Randy. Next time
> it might be me. Or perhaps someday it might be Dave himself. What
does
> concern me is the possibility that it might have gone unchallenged.

I think it is safe to assume, given the last 16 months, that nothing
the RSS Advisory Board does will ever go unchallenged.

This is a good thing. The reason the board is constrained by a
two-week discussion and voting period is to ensure adequate time for
community feedback.

If Dave wants a meeting of the minds here, it would be helpful if he
told us what he thinks this sentence in the spec means: "A RSS feed
may contain elements not described on this page, only if those
elements are defined in a namespace." Does this allow or disallow
namespace elements to core elements in RSS?

At this time, that's the only issue the board is considering for a
spec revision. The others are being addressed in the profile.

When an issue like this arises, there ought to be some means to answer
it with authority, so developers can follow that lead.

There are three potential entities that could do this.

Dave, the lead author of RSS 2.0, could tell people his
interpretation. By nature of his role in the format, it would be
widely adopted.

Sam and the other authors of the Feed Validator could validate RSS 2.0
feeds according to their interpretation. Most RSS publishers use that
validator and follow its dictates.

The RSS Advisory Board, because it has published the RSS 2.0 spec
since 2003 and reaches a sizable audience, could offer its interpretation.

My position isn't that the RSS board should be the accepted authority
over all others.

But when no one else wants the job, by virtue of the fact that they
won't even attempt to point developers in the "right" direction on a
subject like namespace attributes, the board should do it.

-----------------------------------------------------------------------

Sam Ruby to rss-public

rcade wrote:
>
> When an issue like this arises, there ought to be some means to answer
> it with authority, so developers can follow that lead.
>
> There are three potential entities that could do this.
>
> Dave, the lead author of RSS 2.0, could tell people his
> interpretation. By nature of his role in the format, it would be
> widely adopted.
>
> Sam and the other authors of the Feed Validator could validate RSS 2.0
> feeds according to their interpretation. Most RSS publishers use that
> validator and follow its dictates.
>
> The RSS Advisory Board, because it has published the RSS 2.0 spec
> since 2003 and reaches a sizable audience, could offer its interpretation.

These options are not mutually exclusive.

The RSS Advisory Board's profile has largely followed Dave's lead. The
Feed Validator has closely followed the RSS Advisory Board profile's lead.

RFC 2398 was issued in 1998 and describes the syntax of URIs. In 2005,
this RFC was obsoleted by RFC 3986. Closer to home, RFC 822 was later
obsoleted by RFC 2822. But others prefer RFC 3339.

RSS 2.0 is what it is.

= = =

Are multiple enclosures in an item permitted? This is an equivalently
binary question that one could argue that "there ought to be some means
to answer it with authority", but here's how the profile handles that
particular question:

Support for the enclosure element in RSS software varies
significantly because of disagreement over whether the specification
permits more than one enclosure per item. Although the author
intended to permit no more than one enclosure in each item, this
limit is not explicit in the specification.

Why is the question regarding namespace qualified attribute names on
core elements different?

- Sam Ruby

-----------------------------------------------------------------------

Randy Morin to rss-public

7:41 am (2½ hours ago)

--- In rss-public@yahoogroups.com, Sam Ruby wrote:
> I am not concerned about the occasional dispensing of bad advice by
> members of this mailing list. This last time it was Randy.

Sam,
If you were concerned about my answer, then you should've said
something at that time, not save it for later flamebait. The problem is
people like you and Dave who are here solely here to create problems
and not help us or the users.
Thanks,

Randy Charles Morin
http://www.therssweblog.com

-----------------------------------------------------------------------

Sam Ruby to rss-public

Randy Morin wrote:
> --- In rss-public@yahoogroups.com, Sam Ruby wrote:
>> I am not concerned about the occasional dispensing of bad advice by
>> members of this mailing list. This last time it was Randy.
>
> Sam,
> If you were concerned about my answer, then you should've said
> something at that time, not save it for later flamebait. The problem is
> people like you and Dave who are here solely here to create problems
> and not help us or the users.

It is equally possible that I wasn't reading that particular thread
closely, and did not until Dave highlighted it.

- Sam Ruby

-----------------------------------------------------------------------

Dave Winer to rss-public
9:29 am (53 minutes ago)

The other concern is that unchallenged advice might be considered
official. If the group dislaims any official status, as the Advisory
Board did, then there is no problem.

But this group claims lots of official status. That's why mistakes
here are scary.

To Randy, I'm not going to say exactly what it is, because I'm dealing
with exactly this problem myself. People take my word as gospel, every
sentence I type into a blog or mail list about RSS echoes for years as
evidence of something or other, or that there's yet another
incompatible version of RSS. :-)

That's the point. We have to, all of us, get out of the position of
being official. Then we can relax and maybe even have a little fun.

But everyone has to give a little to get there. Me too.

Dave

--- In rss-public@yahoogroups.com, Sam Ruby wrote:
>
- Show quoted text -
> Mark Woodman wrote:
> > I think this is a great proposal by Dave. We've been asking for
> > clarifications on some of these things for years, and now he's
offering a
> > way for us to get them. The board has to be willing to step away
from the
> > notion of revising the spec, but a non-mandatory profile with
Dave's name on
> > it will be taken as gospel anyway. (I hope Sam will join as well.)
>
> The nearest IETF equivalent to the RSS-Profile is a document called a
> "Best Current Practice". By virtue of its name, it is not a gospel.
> For starters, it is not eternal. In any case, neither Dave nor me
> joining the board will cause WordPress to suddenly stop putting
> entity-encoded HTML in RSS 2.0 titles, nor will it stop Snarfer from
> having to deal with such feeds.
>
> I see no harm, nor pressing need, in changing the the address of a
> defunct mailing list to one that is active. I consider all the
approved
> changes in both branches of the RSS 2.0 spec after 11/11/02 to be of
> this nature. I do, however, see considerable harm in revising the spec
> for technical matters. I do see considerable harm in there being two
> separate documents purporting to be "the" RSS 2.0 spec.
Particularly if
> one of them is open to consideration of revisions of a technical nature.
>
> The very notion of a board is problematic. If it consists of people
who
> are chosen due to their active participation in the mailing list, that
> can be made to work, but that does not appear to be the case here.
> Whether or not I am considered a part of the board is not of grave
> concern to me, in any case I have and will continue to participate in
> discussions related to RSS, including on this very mailing list. What
> is of significant concern to me is the inclusion of my name in a
> document for which I neither approve of the process nor of the
> conclusions reached.
>
> I am not concerned about the occasional dispensing of bad advice by
> members of this mailing list. This last time it was Randy. Next time
> it might be me. Or perhaps someday it might be Dave himself. What
does
> concern me is the possibility that it might have gone unchallenged.
> This again goes back to the point of a board consisting primarily of
> people who don't actively participate.
>
> Finally, offline technical discussions of the nature that Rogers
> apparently doesn't want to disclose, is deadly.
>
> - Sam Ruby
>

-----------------------------------------------------------------------

Dave Winer to rss-public

9:36 am (45 minutes ago)

Alan, the spec itself, in the Roadmap section, explains why it is frozen.

http://cyber.law.harvard.edu/rss/rss.html#roadmap

"Having a settled spec is something RSS has needed for a long time.
The purpose of this work is to help it become a unchanging thing, to
foster growth in the market that is developing around it, and to clear
the path for innovation in new syndication formats."

A profile is a document that defines a set of common practices that
improve interop, or simplify a format, or just express how a group of
people are using a format or protocol.

We did a profile for SOAP called "The Busy Developer's Guide to SOAP 1.1."

http://www.soapware.org/bdg

In that case, my company had deployed SOAP in our app and we needed a
document to explain how to be compatible with our software.

What I'm talking about here is something like a BDG for RSS 2.0.

It would answer the questions that Rogers is always asking, with
common-sense answers that reflect how people are using RSS, to improve
interop, and decrease development costs, and help the market move, all
of which I assume people think are good causes.

Dave
- Show quoted text -


--- In rss-public@yahoogroups.com, "Alan Dean" wrote:
>
> --- In rss-public@yahoogroups.com, "Dave Winer" wrote:
> >
> > The two things:
> >
> > 1. Recognize that the RSS 2.0 spec is on the Harvard server, and it is
> > not going to change.
> >
> > 2. Change the mission of this group to working on a profile. Let's
> > come up with a memorable name for the profile that doesn't sound
> > official or mandatory, and let's get to work on solving problems, and
> > then promoting the result to the users.
>
> Dave,
>
> I come to this discussion with no preconceptions and no bones to pick.
> I *am* a professional developer, but I have not been active in the RSS
> space. So my questions are entirely based upon general principles,
> rather than the specific case. If I therefore misunderstand, I beg
> your indulgence.
>
> Q. Why should the spec be immutable? Specs *do* change. HTML does, for
> example. From a general viewpoint, the best practice is to ensure that
> changes are backwards-compatible, rather than preventing any change.
> You are quite forthright on this point and I therefore imagine that
> you have a darn good underlying reason for this position. Could you
> share that reason with the list?
>
> Q. What do you mean by by 'profile'? Does this refer to deeper
> explanatory text?
>
> Regards,
> Alan Dean
> http://thoughtpad.net/alan-dean
>


-----------------------------------------------------------------------

Dave Winer to rss-public

9:40 am (41 minutes ago)

Randy, no one here is flaming.

Let's keep it that way, okay??

Dave
- Show quoted text -


--- In rss-public@yahoogroups.com, "Randy Morin" wrote:
>
>
> --- In rss-public@yahoogroups.com, Sam Ruby wrote:
> > I am not concerned about the occasional dispensing of bad advice by
> > members of this mailing list. This last time it was Randy.
>
> Sam,
> If you were concerned about my answer, then you should've said
> something at that time, not save it for later flamebait. The problem is
> people like you and Dave who are here solely here to create problems
> and not help us or the users.
> Thanks,
>
> Randy Charles Morin
> http://www.therssweblog.com
>

-----------------------------------------------------------------------

Alan Dean to rss-public

9:53 am (29 minutes ago)

On 5/27/07, Dave Winer wrote:
>
> Alan, the spec itself, in the Roadmap section, explains why it is frozen.
>
> http://cyber.law.harvard.edu/rss/rss.html#roadmap
>
> "Having a settled spec is something RSS has needed for a long time.
> The purpose of this work is to help it become a unchanging thing, to
> foster growth in the market that is developing around it, and to clear
> the path for innovation in new syndication formats."

Dave,

I can accept the "no new features" part of the roadmap. One could
argue that this facilitated the development of the Atom spec instead
of trying to get RSS to meet those goals.

However, (and please correct if I am wrong) I was under the impression
that the proposal I saw was regarding a clarification of the spec
(basically, an errata entry), rather than feature-creep, to simply
replace the word "elements" with the phrase "elements and attributes"
in the following sentence:

"A RSS feed may contain elements not described on this page, only if
those elements are defined in a namespace."

Is this proposal not covered in the roadmap you linked to by the phrase:

"We anticipate possible 2.0.2 or 2.0.3 versions, etc. only for the
purpose of clarifying the specification ..."

http://cyber.law.harvard.edu/rss/rss.html#roadmap

Regards,
Alan Dean
http://thoughtpad.net/alan-dean