Arthur, While there is no question that the kind of information you request is very valuable and should be provided somewhere, we've learned from decades of writing and reading these specifications that including such information in the specifications themselves is often counter-productive. Yes, I realize that this sound sort of counter-intuitive.
The problem here is that a spec has two distinct lifetimes, one much longer then the other. In the first lifetime of a spec, the focus is on drafting the thing and building consensus as to what should be in it. This is the phase during which the non-normative "rationale" information is of primary importance. However, once the spec has been drafted, reviewed and accepted, it turns out that all that non-normative material ends up being a burden on implementors who "just want to implement the thing." Once we've gotten the Standard accepted, the explanations for why it is written as it is are often irrelevant or only of interest to academics. The meat of a specification is its normative clauses and surrounding those normative clauses with non-normative background material makes it harder for implementors to read the thing (since it is much longer) or even to distinguish between what is normative and what is not. In some standards communities, this problem is addressed by the practice of issuing an explicitly non-normative "Rationale" document that accompanies the formal normative specification. However, we've discovered through painful experience that these documents are usually not as complete as they should be, often get out of sync with the normative documents, and consume tremendous quantities of effort that might have been better used on drafting a better specification. It is unfortunate, but that is the case. You should probably realize that there exists a large and constantly changing informal "community" of people who are now and have been discussing the issues that lead up to specs like this one for many years now. Certainly, within that community, there is an imperfect agreement on the various rationale issues -- but an agreement good enough to ensure that we can often make useful progress. If you wish to join this community, you should know that it is open to anyone. Just start monitoring the various related mailing lists and you'll rapidly pick up the threads that will lead you back to all the information you might need. Also, be aware that all IETF working groups and many other standards groups try hard to limit discussions to mailing lists and thus you'll find that the full history of these discussions is available even years later. And, if you're having trouble finding links to some ancient conversation, mailing list members are usually quite willing to respond to a query on the subject. Please remember, however, that most of the people in these discussions are on their own time and aren't necessarily getting paid or otherwise explicitly rewarded for what is often a tremendous amount of time and energy expended on providing the Internet with good specs. Anyway, welcome to the discussion. bob wyman On Fri, Mar 5, 2010 at 8:16 AM, Arthur Coleman <[email protected] > wrote: > I would like to see a first Introductory section to the spec (After > notations and conventions) that explains at a high level the purpose > of the spec and ways it can be used (use cases - although that could > be a separate section. Your spec assumes that every already knows the > deep technical details of atom and RSS, which is a bad assumption now > that the spec if gaining notoriety and traction. As an example, I > read numerous online pubs every day and never heard of this spec until > yesterday. I have found only one article from SearchEngineLand on the > subject from last July and then there was one yesterday that caught my > attention - so a lot of folks are about to discover this standard as > it starts to percolate out who previously had little focus on it > (because Google has suggested they will now implement some form of it) > Here are the elements I'd like to see: > > Section 3: Overview of the Spec > ---------------------------------------------- > 1. What is the purpose of the protocol > 2. What is the history of its emerging - in other words, someone went > out and said "there is a need" - what was their motivation. Section > 8.1 covers a tiny part of what I have in mind here - I would expand > that section and put it here > 2. Who needs it and why? Specifically identify if this spec is > intended for me as compared to the general need (e.g. programmer, > product manager, publisher) > 3. How does it differ from the RSS and Atom protocols. > 4. Is it "better" than RSS and Atom - e.g. is it an evolution of > those protocols or does it go in a different direction? (I note that > it builds on Atom, but does that mean it is an extension or just using > it as a way to speed and simplify adoption) > 5. Of the existing problem, what portion is this spec focused on > solving right now vs what it could solve and what direction will it > take toward solving the wider set in the future (again Section 8.1 > applies here as well). > > Section 4: Use Cases > -------------------------------- > Search Engine > Individual Blogger > Real Time Web Service Provider (e.g. yourversion as an example) > Enterprise > Other? (I haven't a clue) > > I would be willing to write these sections as a way of finally forcing > myself to learn all these specs (RSS, Atom, and pubsubhubbbub in > detail), but I would ask that the leads be available to interview and > for guidance when I have questions. If you wish to see examples of my > writing go to my blog at http://www.aboutonlinematters.com >
