Tim Bray: We need to crystallize and refine and clarify and
write it down so that any literate human can write it and any
competent programmmer can implement it and no commercial interests
can hijack it. That’s all.
My experience with standards bodies exactly matches Tim's.
We should have a small core of approximately
required elements. Ones that we know everybody can
support. Not guess, but know.
Author. Link and Id. Two dates. And
content. We pretty much are already in the ballpark.
Perhaps title and we have a core.
We can still encourage innovation and experimentation - in
extensions. Tim Bray was one of the authors of
one such way to
Absolutely. Follow the well-known mantra: release early, release often. As long as it's well-specified, and people can solve all their current needs with the 1.0, get it out ASAP, and leave the truly interesting stuff for 2.0.
Now, completely ignoring my own advice, something I would like to see, which I very much doubt will actually ever go in, is the abstraction of people.
It seems that there are quite a few specs that include information about people as part of the document. RSS/Echo need some way of identifying authors. FOAF is primarily talking about relationships between people. There was talk of putting a URL into a field for comments on a website that would identify you.
Wouldn't it be better to just rip that all out, and replace it with a single element type that has http://www.example.com/jim.person or similar as the contents? It needn't be a massive specification for the purposes of Echo, just name, email/hash, URL to website. Anything else can be namespaced away for people to play with. After a while, the common extensions can be put into the 2.0 - but this can happen separately from Echo's releases.
I realise there are complexities, such as having to handle two files and so on, but whenever I see this area of the specifications, my OO sensibilities kick in, and I want to refactor it all. I also understand that various approaches are already out there (isn't one of them called Ping?) - but these are too complex for a simple format for now. Pet peeve. Never mind.
Extensibility through namespaced modules seems appropriate for vertical applications with (more) tightly coupled client and server, but their existence and availability doesn't do much to improve the horizontal application landscape unless the vast majority of producers support them. I don't see how you get consistent adoption of FOAF, Comments, etc without (at least) adding these modules to the core spec 'brand', and evangelising adoption of the more complex spec to the roadmap signers.
I would echo the comments made in another thread about needing an order of magnitude functionality leap. The only reason that users should care is because of the programmer claims that progress is being stifled. If the group converges on a community owned clone of RSS as the primary deliverable, I hope the progress everyone expects the spec to allow doesn't become an afterthought.
Unless you plan to describe different required elements for "Echo as archival format" vs. "Echo as blog posting format" vs. "Echo as site syndication format" I disagree with your choices of what should constitute the core seven. Id makes no sense when posting a comment, neither does having two dates IMHO.
These sorts of things have a habit of spiralling out of control. Everybody has their own ideas about where the spec should go, or their own little tweak.
The first version of a replacement for RSS should not be so bigheaded. Let's get the minimum necessary to replace RSS, so that people can begin implementing it quickly. Once there's a sold base to work from, then people can think about new functionality. If there's a 12 month gap between now and the new format, then a) that's 12 months without a replacement for RSS, and b) the momentum that is currently building behind this new format will peter out.
Jim, I hear you. I guess I feel really strongly that the opportunity for the greatest innovation is at the reader side of the value chain. These tools are constrained by available data, and by the razor thin interactivity defined between reader and site (get file).
I do not think the focus of tool vendor attention is sustainable through rounds of specs, their interests will diverge again. Right now there is a common interest in getting onto a public foundation, and people seem willing to do some heavy lifting to get there. I don't think it's safe to assume the critical mass will be there for subsequent spec revisions.
I'm curious. Exactly how is a blog posting client supposed to generate an id before sending the post especially when the ID is supposed to be a URI and not jus a GUID? There may be some ways for the client to track posting date and last modified date for blogs that allow people going back and editing their posts (I believe Joe Gregorio's blog is the only one I know that supports this feature) but this is an edge case feature not something that should go in the main spec.
I assume your comments were in reference to 'Echo as a syndication format' which explains the confusion since mine were about 'Echo as a blog posting format'.
Tim's remark and the shortlist are fair enough, but wasn't the original idea to develop an editing API (to serve a similar purpose as the Blogger API) as well?
This being the case then it's not simply a matter of extracting human-variant-RSS syntax and baking it, but of looking what is required at a system level and ensuring things are provided consistently across syntax, API and whatever extension inferfaces there are.
Not invention, engineering.
The issue of extension interfaces also relates to the use of namespaces. Namespaces provide a way of adding elements not in the core, but they don't describe how the external elements should be interpreted. This isn't such a major issue for the stovepipe newsreader kind of application, but for various other applications (such as listed by Tim on his blog) and especially where machine-processing (such as merging and sorting) this could be significant.
Of course it won't be possible to cover every possible extension individually, but things like the difference between adding an extension element at the feed level of nesting compared to an entry level needs stating.
No Inventions No Inventions. Tim Bray: We need to crystallize and refine and clarify and write it down so that any literate human can write it and any competent programmmer can implement it and no commercial interests can hijack it....
Congrats on the big mo you got going. Here's one suggestion I'd like to see acted on.....
To alleviate (rightly so) Dave's comments about IBM (your employer) 'taking over' Echo - what might you do?
What can you do to relieve the conspiracy theorists amongst us? Afterall this is the FIRST time (since Netscape) that a BigCo has cared enough to 'let' (or shall I say 'assign') an employee to actually worry about this stuff - full-time.
So you have to see it from 'our' POV. Can you come up with some sort of safeguard/mechanism - guarentee - to make sure YOU guys (i.e. BigCos) take over. OASIS. Liberty Alliance. ISO. My experiences with standards bodies and BigCos has been universally HORRIBLE!
On the complexity thing: I second the motion to keep the EchoCore small and compact and move stuff out to modules that are included by Namespaces. Use FOAF if you want to talk about people, don't reinvent RSS and FOAF and GEORUL and DublinCore and whatever else springs to mind. This won't take off if people can't implement it (or can implement it, but don't do, because it would be too much work).
If you want to see where a standard ends when everybody pulls it's own pet peeve into the core, have a look at X400. :-/
Please keep the EchoCore compact. Grokable. Easy. Maybe even stupidly simple - it helps with taking off. Move complex stuff to modules, give namespaces to them, use existing modules.
Georg: At the risk of sounding stupid, why? One of the things I'm starting to realize is that the individual contributor/small company ethos surrounding this space is masking a problem that even medium size companies address. In a software development effort it's pretty normal to have a Product Manager write a user requirements document which focuses on who the users are, and what their needs are. In the case of echo it's not clear if the 'users' are blog tool authors, writers, readers, etc. The preponderance of voices seems to be software developers hypothesizing that if there were a better spec great things would happen. My question is how can we say great things will happen without describing them? And once we know what the user requirements are, isn't that the time to define a spec that allows software to meet those requirements?
full disclosure: my bias is towards focusing on the users of feed-readers, as I see this as the largest group, and the one that everyone else has a vested interest in seeing grow. Users with feed-readers create demand and flow for feeds (content producers) who in turn create demand for compliant content authoring tools.
I've spent the morning thinking about the idea of soliciting feedback emails from all the feed-reader tools (SharpReader, NetNewsWire, etc...) and taking a cut at aggregating this into Product Requirements Document type of thing, that is focused on the functionality that end users are writing in asking for. This is obviously limited, but it would cast a far wider feedback net than the core of technologists who are framing the debate today. Not sure what I want to do here yet, and would love to hear people's thoughts.
In reading some of the comments from international users, I'm beginning to see that the lack of a required language attribute is an issue. The reason appears to be that most entries start out "local" so language is left unspecified. If I recall correctly, there is a language code for "unspecified" such that current systems could put that in as a placeholder.
But as soon as I say, "current systems could", we're in to the gray area of invention.
The magic number. Great paper pointed to by Sam Ruby (in the context of 7 elements being about what's needed for Echo). Quite a bit of evidence suggesting 7 (+/- 2) is a good number for our heads to handle. The Magical Number Seven[Raw Blog] Yes -...
Josh, FYI -- as a designer of a "feed reader" and the lead designer on RSS 2.0 (despite what some say there were other contributors) -- that's exactly where the features of 0.92 and 2.0 came from, to back up features in the aggregators.
Josh, I agree completely. As someone said elsewhere, this isn't a spectator sport. If you're not ready to actually solicit all the information present the results, please at least raise the visibility of the issue on the wiki.
My question is how can we say great things will happen without describing them?
Personally, I will yank my "Echo" endorsement the second I see things start to veer away from "let's build an extensible spec based upon known best practices" toward "let's define the future and do great things".
I'll do my own innovation, thanks. I'm here to interoperate... nothing more, nothing less.
Not adding much re: the technical discussion here, other than to agree with Danny -- we also need to look at the data model from an API perspective. Syndication feeds are not a primary concern. Please --enough with the aggregator and newsfeed on this. Any aggregator beyond a personal hack should be able to managed different XML vocabularies. But, the API -- that's the biggie.
However, that's not why I'm commenting, or not only reason I'm commenting. I'll probably also put this into my weblog, but I wanted to address Mike Sanders and Marc's concern about IBM's affiliation with Sam. Sam, sorry for my rude intrusion with this when the questions are addressed to you...
Marc and Mike and whomever -- HP has released several people in their R & D division to work on RDF almost exclusively, and the only way you really know this is if you download Jena, a Java API they also created. HP has no more control over the RDF specification than any other company.
You may have noticed that the wiki for this is hosted on Sam's site, which is cornerhost, not IBM. Too bad in some ways, because this has been a burden to the smaller company -- but they've managed it commendably.
IBM cannot even attempt to take ownership of this because Sam's contributions are too blended in with every one else's. That's the point of a wiki -- open contribution. If IBM, or MT, or Blogger or any other "BigCO" (a term I find chi chi clever, and therefore annoyed at) tried to take over this, to patent it or copyright it, it would be laughable.
I imagine that IBM doesn't mind being indirectly associated with new technology, which is the reason why lots of companies release their folks for this type of effort -- where do you all get the idea this has happened before? -- to have a little of that cutting edge glow rub off on them, keep their name in the game.
The whole point on this effort is so that no one can own any of it, so I find it difficult to read these suggestions that IBM or some other company is trying to 'own it'. I own it. Sam owns it. Dare owns it. Phil owns it. Josh owns it. Dave Winer owns it. Marc, you own it. Mike S, you own it.
If I can get my dear sweet mother to weblog, she owns it, too.
Now, can we leave this one be, and focus on the work?
Sorry, Sam. I know these were addressed to you. I was just a bit 'agitated' when I read these comments.
"The whole point on this effort is so that no one can own any of it, so I find it difficult to read these suggestions that IBM or some other company is trying to 'own it'. I own it. Sam owns it. Dare owns it. Phil owns it. Josh owns it. Dave Winer owns it. Marc, you own it. Mike S, you own it.
Now, can we leave this one be, and focus on the work? "
I agree completely. Can we please focus on the task at hand instead of indulging in conspiracy theories about BigCo's stealing the hardworking sweat of the masses?
I read somewhere recently that Microsoft are also plotting to take over the syndication industry (pull out their CDF patent and claim back-payment perhaps?). Unless of course everyone supports RSS 2.0...
7 things - at once. The magic number. Great paper pointed to by Sam Ruby (in the context of 7 elements being about what's needed for Echo). Quite a bit of evidence suggesting 7 (+/- 2) is a good number for our heads to handle. The Magical Number...
Dare, that's the kind of thing an employee of Microsoft ought not be indulging in. I can show you a quote from a MS officer, Craig Mundie, at the Open Source Convention a couple of years ago, where he told the developers to go get some patents because Microsoft wouldn't let them implement things they had patents on. One of the most shameful days ever for our industry. Fact is you work for a company that's aggressive with patents. You can't dismiss that with sarcasm.
Roger, I'm not sure how to express what I'm talking about better, but I'll try.
Is echo an attempt to essentially (and openly) clone RSS + Blogger API + metaweblog API or is it an attempt to define a set of data and API standards for the weblog editing, syndicating, and reading space based on what everyone has learned over the past few years. If it's the first, I'll shut up and stop pushing these questions, if its the latter I'm only suggesting that a bit more focus on who the users are, and what they need to come out of this, is in order.
Josh, it is a mixture of consolidation and applying things we've learned. It appears to be strongly based in current practice and not an effort to break new ground. Even there, though, it is very important that there be a focus on users as well.
Tim Bray: "what the Echo-that-was project should be about picking the stuff thats already been proven to work and be interoperable, and writing it down in a clean, clear way, and arranging for the specification to be clearly out of the clutches of...
A "profile" is typically a subset, and a subset would mean making things we're currently saying are "required" into "optional". A "profile" could be interpreted differently, how about an example?
On the other hand, a definition of the core, and then profiles that indicate which are required in which contexts could be possible. I'm not sure that a particularly valuable thing, though. Especially when one starts recognizing that the profiles have to/should also be recommending various extensions.
It's almost better, in that context, to define the core and have a matrix of situations where they are most applicable.
If it's the first, I'll shut up and stop pushing these questions...
Last things first: I don't want you to shut up. As far as I'm concerned, you should continue to make your case as long as it makes sense to you. I'm just making my individual position clear. If the direction for which your seem to be arguing were to become ascendant, I'd withdraw.
No hard feelings, no rancor... it would simply mean that the project's goals and mine had diverged.
Is echo an attempt to essentially (and openly) clone RSS + Blogger API + metaweblog API or is it an attempt to define a set of data and API standards for the weblog editing, syndicating, and reading space based on what everyone has learned over the past few years.
As far as I'm concerned, it's about easy interop. Full stop. That means figuring out what everyone is doing, identifying the features they have in common, and enshrining those features in a series of simple, open, and extensible specifications. If those specs look like clones, so be it. (Might happen with syndication, but less likely with the API.)
I'm only suggesting that a bit more focus on who the users are...
In the case of an interop specification like "Echo", the users are the developers of the blog tools/CMSs, aggregators/newsreaders, and associated gadgets. Their need is an open, extensible, and simple means of talking to one another.
Any spec that starts wondering who my users are and what's best for them, OTOH, has just jumped the tracks. As I said, I'll do my own innovating, and it's my job to look after the needs of my own user community. "Echo" should simply make that job easier, not redefine or usurp it.
(BTW, if the above sounds cranky, I apologize. It's meant to be emphatic, not pissy.)
Roger, in the spirity of exploring where you're at, may I suggest that the users are developers directly, but that the decisions that are made define the data set that translates into features for end users. For example: an agreement to interoperate on an authenticated feed requests creates an entirely new market segment and area of possibility for users. Without discussion, there will by default be no interop in this little area, and (by extension) no personalized feeds for end users. The list goes on and on. With every decision to add or omit something from the core standard, that everyone agrees to support, future capabilities live and die, and in some of these cases entire markets become servable or are precluded.
I totally agree that you should serve your users, you should innovate for them, and you don't need my help to do so. Echo is defining the outlines of a common playing field that all of the tool vendors will share. I'm not arguing to get between you and your users, I'm arguing for a discussion about broad outlines of user communities and what the spec would require to support their needs. Look back at Tim's post about getting his credit card transactions from his bank as a feed. Is this a scenario that echo should enable? If so, what are the technical requirements to make that possible? That's the kind of questions I'm looking to see answered. And that's the process I'm advocating: Define the scenario's that echo will make possible, then define the data/APIs to support it. Make clear decisions about cutting or keeping in light of the end user value derived from each decision.
For example: an agreement to interoperate on an authenticated feed requests creates an entirely new market segment and area of possibility for users.
Sure. But that agreement can take form in an extension of the core. It's not something we're all doing today, so one would be hard-pressed to describe authentication as a fundamental component of a well-formed entry. And if it isn't part of a well-formed entry, it doesn't belong in the spec, IMO.
With every decision to add or omit something from the core standard, that everyone agrees to support...
With every feature that is added, the incentive to support the standard decreases. Literally. Every time I see someone introduce a pet concept or unique feature and lobby for its implementation, I cringe. I've got about 100 such things for which I could campaign... but I haven't, and I won't. Because those would only introduce 100 new arguments, 100 new issues to politicize, and 100 new reasons to slow things down.
Look back at Tim's post about getting his credit card transactions from his bank as a feed. Is this a scenario that echo should enable?
Directly within the core specification? IMO, absolutely not. In an extension? Sounds good to me.
You make some very good points. I don't think that the issue is primarily one of ownership, but rather control. In many companies the IT department does not own the computers and software, but they sure control how they are used. That is just a simple example.
I just want to make clear that my points are in no way a question of the personal integrity of Sam, Tim or Joshua. However, if you look at the totality of their objectives and the objectives of the companies they work for, you will clearly see some significant misalignment.
As a thought experiment, what does the best possible outcome of this effort look like in one or two years?
Some questions to think about:
Is there one RSS/Echo format or many to be supported?
Who is deciding when the next release is and with what features?
What vendors and companies are using RSS and for what functions?
Related things to think about.
Is RSS a mainstream corporate technology?
Who is the leading blogging software vendor?
Who is the leading RSS consumer and producer?
Are Google, Microsoft, IBM, Six Apart in the pool?
What percentage of the market do they own?
How big a part is RSS in their strategy?
This effort is very noble and a great experiment in collaborative development. But the technology is too important, and it is unrealistic to expect the major corporations to sit on the sidelines. They have a responsibility to their customers, shareholders and employees to get involved now.
Roger: the core does matter, and yes, most area-specific functionality should be in modules, but it does help to look at some area-specific interests when you defined the core. An example which I saw beign discussed somewhere on the wiki, is the requirement for <title> tags. This instantly makes everything Echo syndicates require a title, and therefore kludges have to be made when the stuff syndicated has no title (e.g. I know of an RSS feed for a fortunes file for example, which has no titles). Does a title mean anything in the context of a credit card account? Does an author tag? And for a fortune file? Or a CVS logentry update? Do either of these fields really need to be in the core or can they be in a commonly used extension?
While it may seem a little spurious to be doing something as boring as defining an number of use cases, it seems prudent now to do a few, both current practices and more wacky ones, so we can consciously decide where to draw the line. It'd be nice to at least attempt to avoid situations that go along the lines of "hey, it would have been nice to use Echo for this, but we made such-and-such a requirement - why were we so stupid?"
Yes, I realise we can always make current compulsory tags optional later, or even deprecate them later, but these things can be architecturally unsound to do at a later date.
Do either of these fields really need to be in the core...?
The answer is fairly simple, in my view:
No, if the core is meant to define an abstract data distribution mechanism.
Yes, if the core is meant to define an interop standard between blogging tools and associated gadgets based upon the concept of a well-formed entry. And given that the roadmap I've "signed" speaks specifically of a "weblog format", I'm inclined to go with this second answer.
That doesn't mean that someone can't dump bank balances and stock quotes into an Echo feed, with or without an appropriate module. It just won't be built to specifically handle such a task.
Although as an aside, it's arguable that the loosely defined RSS 2.0 will continue to be the best way to syndicate random chunks of content, with Echo being a richer, more carefully specified, blog-focused alternative. It might make Dave cringe to hear it suggested, but it's possible RSS 2.0 could end up being used for field-testing of prototype syndication efforts... throw it out there in a loosely structured format where people can use it, and if it catches on, evolve it into a more stringent Echo (or other format) module.
That's part of why I support both Echo and RSS 2.0. One need not be a replacement or competitor for the other.
Very out of sequence but commenting on the sentence "We should have a small core of approximately seven required elements."
"Please don't screw with the core (of RSS). Now here's my interpretation of the core that's common to all the versions of RSS, and it's both needed, required and sufficient.
<channel> //1 and only one
<item> //0 or more
If every RSS vn.nn, SSS, Echo, Pie or whatever variation supported just these, we could continue to evangelise it, build aggregators and generally get on and implement even while lots of people were experimenting with extensions. So I'll say it again.
While totally invisible to the bulk of humanity, there's been a storm in a soup bowl of late as the Great and Good of blog-tech have been focussed into a Wiki to design a successor to RSS and the Blogger API - the name 'Echo' has been mooted as a...
hey, what is this sight 4 if there is no inventions? r u just having this sight 4 the fun of it? well i’ll expand this message some other time when i feel that this site is important enough to go to and waste my time!!!!!!!