It’s just data

necho 0.1

I've taken a 2003/07/01 snapshot of the maximal example of the format previously known as echo.  The reason for this exercise is that I plan to start prototyping using this as a baseline.  I invite others to do likewise.  Let me know via comments of any implementations.  In particular, I am interested in templates that others can use.

Obligatory disclaimers: everything is subject to change.  Here are my assumptions at this point, also subject to change:

Feed elements

Entry elements

Feel free to challenge these assumptions... they are not cast in stone.


i've got a live echo feed up at my site, at http://www.joelonsoftware.com/echo.xml

Posted by Joel Spolsky at

First shots at it: http://philringnalda.com/feed.xml and http://philringnalda.com/templates/feed.xml.txt

Afraid you'll have to live with all local timezones until I write or steal an MT plugin to return a UTC date, though.

Posted by Phil Ringnalda at

+1 on Necho as the real name.

Posted by Joe Madia at

Phil, your template only works for valid XHTML, which is not terribly common.  Here's an MT template that works for arbitrary HTML:

http://diveintomark.org/about/templates/index/necho-prototype-20030701

Example output:

http://diveintomark.org/xml/necho-prototype-20030701.xml

Posted by Mark at

Let me see if I can get this straight.

Joel:

- Your <feed> should only have modified, not created and issued. The modified should be in UTC and as such not include a time zone.

- Likewise, entry/created and entry/modified should be in UTC.

Sam:

You might want to include a specification for author in here. Also, why is a subtitle for a feed necessary? I don't see that, people might just want to have a title, no subtitle involved. And finally: shouldn't <author> and <contributor> be merged, like <author is-contributor="true"> or <author main="true">?

Posted by Manuzhai at

Right, I couldn't figure out what to do with the fact that I'm unable to output valid HTML, thanks to a bunch of illegal attributes named "/" in my empty tags, so I had to go with XHTML.

Posted by Phil Ringnalda at

Created, Issued, and Modified?  Isn't that overkill?  Also I thought the general consensus was for just Issued and Modified.

A feed level "sub-title" maps to an RSS channel description?

Changing the entry level core text element from "description" to "summary" seems to more narrowly proscribe its possible uses.  Can it no longer be used for an excerpt?  Or the entire body of the message if I so choose?  The naming of things creates expectations.

Posted by kellan at

Although I have no idea if Sam was seriously suggesting Necho as a potential name or not, I like it.  A lot.  After a quick check, I discovered that necho.org was available.  Well... not any more.

In the extremely unlikely event that the name Necho is a contender for the final name then I publicly promise to donate the domain name necho.org for use in whatever way is deemed to be most beneficial to the project.

(In the much more likely case that the name gets passed over, I'll probably just let it expire.)

So... head on over to http://intertwingly.net/wiki/pie/ProjectNameProposals and vote for Necho!

Posted by Joe Madia at

When putting straight xhtml in the feed, what should the element be?  div? xhtml:body?  Or is a sequence of p tags ok?  Should the spec say something about this or leave it up to interpretation?

Posted by Chris Wilper at

I think that title should be optional.  In Joel's feed, the titles are generated.  Vast majority of Blogger blogs don't have titles.

If we absolutely want to require seven elements, we can specify "origin" which is a source blog URL or id.

BTW, I'd prefer to allow for non-plaintext titles, while specifying that titles SHOULD be plain text.

P.S. Mostly API related: http://www.intertwingly.net/wiki/pie/BloggerProposals

Posted by Misha Dynin at

Due Process

The Echo project switched gears tonight, and in doing so moved into deep water. You see tonight was the ...... [more]

Trackback from LaughingMeme

at

Due Process

The Echo project switched gears tonight, and in doing so moved into deep water. You see tonight was the .........

Excerpt from LaughingMeme at

I'm a somewhat baffled by having 'subtitle' as optional in entries (i.e. input) but required for feeds (i.e., output).  Where does it come from if the entry was not given one?

And Necho isn't such a bad name:
"fl. 670 b.c., lord of Saïs, Egypt. He was confirmed in his holding after the Assyrian conquest in 670; he was later taken to Nineveh in chains for plotting to revolt but was pardoned and restored. He probably fell opposing (663) the Nubian reconquest under Tanutamon. "
http://www.slider.com/enc/37000/Necho.htm

Posted by James Britt at

That makes me like Necho a lot. :D

Posted by Manuzhai at

Hi Misha,

RE: Title requirement.

I would prefer to see a title required, but it can be empty.  Why?  Low barrier of entry on one end of the spectrum, and an "encouragement" for new tool authors to follow a practice that encourages such a thing.  Good article Jon Udell: Why titles matter

Posted by Chris Wilper at

Why can't you do this stuff while it's daylight where I live?  I'm right about to go to sleep and find out that I have to implement "NECHO" instead.  <s>Have some compassion, man!</s>

Necho feed for messy-78

b2 "template" for creating such a feed

Posted by steve minutillo at

Sam,

Looking at existing blog tools (and aggregators), there's one glaring omission: category aka topic aka (dc:)subject.

Here's an echo feed with a subject element included for each entry.

http://www.mystartmenu.com/blog/necho.xml

If I were voting on core elements to support, subject would rank higher than subtitle in importance.  As a practical matter, it's like pulling teeth to get people to enter titles, much less subtitles for their entries.

Posted by Chris Wilper at

I pinged Sam with this a couple days ago, but I've updated my template to include modified:

main feed:
http://journurl.com/support/users/admin/index.cfm/template/echo

individual entry:
http://journurl.com/support/users/admin/index.cfm/mode/article/entry/557/template/echo

Sadly, it looks like I won't be able to provide an Echo representation of search results the way I can with RSS 2.0. Echo just has too many required elements at this point, and the search engine is optimized to only return the bare necessities.

RSS search feed for "echo":

http://journurl.com/support/users/admin/index.cfm/mode/search/s/echo/template/rss

Oh well... can't have everything.

Posted by Roger Benningfield at

Necho feed here

In response to Sam's post, here's my necho 0.1 feed.

Necho needs categories.  Pyblosxom needs some hacking to accomodate all the info that can be in a necho feed.  That hacking will have to wait a bit.... [more]

Trackback from Ted Leung on the air

at

The src attribute of the content element does not mix with the other attributes (type and xml:lang).

Also, its type attribute feels awkward. If the content is an XML application, using its namespace is more effective; if it's pure text, the situation is obvious. And if you want other stuff in there, why not use the data URI scheme (RFC 2397)?

Author homepage and weblog attribute names are unnecessarily restrictive IMHO (a HTTP URI is just one kind of URI).

Let's please drop the feed-level modified element, this is transfer protocol stuff.

Posted by Arien at

Necho feed here

In response to Sam's post, here's my necho 0.1 feed. Necho needs categories. Pyblosxom needs some hacking to accomodate all the info that can be in a necho feed. That hacking will have to wait a bit. ...

Excerpt from Ted Leung on the air at

I can't see the reason behind feed:subtitle being required.

I don't even know what it would be for my own blog.

Posted by Phil Wilson at

Unless it really means "description", of course. Semantics count.

Posted by Phil Wilson at

I can't see the reason behind feed:subtitle being required.

+1 ... my blog didn't have one until a few weeks ago, and no JournURL blog has one by default.

Posted by Roger Benningfield at

First go at a necho feed here:  http://bluesky.entrouvert.be/necho

Posted by Frederic Peters at

Just a thought - I wonder if it might be worthwhile at this stage to flag identify the things that can't be round-tripped to RSS 2.0 (via XSLT or whatever). Presumably we can be fairly sure that (in isolation at least) the bits that will round-trip will work.

Posted by Danny at

* What if we'd like to include a "teaser", "excerpt" or "introduction" in addition to a "summary"?

  * What if there are more parties involved but an "author" and zero or more "contributors"?  What about an "editor", "publisher", "designer", "content provider", or even a "photographer" like you have in conventional print?  Do they become "contributors"?

  * How can we support multilingual content?  (A story that is available in multiple languages.)

  * For single-user weblogs, having to duplicate the <author> block in each entry might be a lot of duplication (and wasted bandwidth).

Posted by anonymous at

Unescaped HTML directly within an XML document?  I don't like that.  How are people meant to validate feeds with that kind of thing going on?  Ignoring namespaced elements is easy enough for the XHTML case, but including inline HTML in XML is just plain wrong, imho.

Posted by Jim at

Chris W,
Are you intending for categories to be feed-specific? That is, the category 'Cheese' in one feed should be considered different to the 'Cheese' in some other feed?

If it is feed-specific, then we have the problem that a single site generating multiple feeds will not be able to (read: not be supposed to) match the categories between feeds.

On the other hand, if they are just some arbitrary global identifier, two authors uses of the same keyword may conflict.

Perhaps category should be yet-another-URI(tm), which (like unique ID) does not actually have to point at anything as long as it is guaranteed to be a unique category URI. For the aid of tools, though, a displayable version of the category should still be provided.

Perhaps some other kind of XML application can be used to return a category list mapping the URIs to pretty names for a given set of feeds? (referenced from the feeds themselves so that tools that can support it can retrieve and cache it for all of the feeds which reference it)

Whatever -- just some thoughts.

Posted by Martin Atkins at

I'm concerned about the verbosity of a Necho document, considering the many required elements. My RSS feed is the most heavily trafficed page of my site, and the number of subscribers appears to be increasing on an almost daily basis. I've implemented conditional GET on it, but it is still a huge bandwidth hog as every subscriber sucks down the whole feed every time I post an update (and I frequently post several updates a day). The additional elements required by Necho mean the feed could be significantly larger, and will thus absorb even more bandwidth. Times that by the many, many blogs out there that will eventually be using Necho and that's a lot of bandwidth being burned.

I know that the thinking behind the many compulsory elements is that it makes Necho easier to parse, but I am not convinced that the trade off in terms of the size of the feed document is worthwhile. The added difficulty in extracting information can be mostly avoided by clearly specifying some simple algorithms in the Necho specification document. For example: If [issued] is provided and [modified] is not, consider the issued date to be the date the item was last modified.

I am also strongly opposed to different ways of representing dates being used in the feed. This adds a great deal of extra complexity for implementors without adding any real value, at least as far as I can see.

Posted by Simon Willison at

I have problems with some required elements, too. For example the required author at entry elements doesn't make sense with one-person-blogs. Maybe this would be better with a required author at feed level and optional author at entry level? I could live with the autho-at-entry-level, too, but it feels clumsy.

But what makes problems is the required modification date. I can live with optional modification dates, but not with required ones: PyDS doesn't keep track of modification dates. Publication date should be required to make sure that entries have at least one date. Other timestamps should be optional. Oh, and the default for the timezone should be the same with all timestamps (either all default to UTC or all default to localtime - UTC would be what I prefer).

And the subtitle is something I don't have, too. Ok, I could cook up some (implement it in PyDS or just fill it with an empty string), but that would be cheating, wouldn't it? ;)

I think more elements should be made optional. This feed stuff should be able to be small, if the feed is of minimum character (for example I build RSS feeds out of eBay searches, out of television program and other stuff I like to monitor in my aggregator).

Posted by Georg Bauer at

I still don't get the subtitle element. It's not in Dublin Core. Where'd it come from, and who needs to use it? Even as an optional element, it seems to be an extra doodad that in practice won't see much use; simple is better.

Posted by Bryant at

Golly Gee but that was quick!

Posted by Jonathan Smith at

I've added a comment about subtitle to the bottom of the EchoExample page. People who have mentioned issues with it here, should add their opinions to that page as well.

Posted by Gary at

I've identified an optimisation for Necho feeds that eliminates the need for duplicated author information in every entry, described here: http://intertwingly.net/wiki/pie/EchoFeedWithAuthorRefs

Posted by Simon Willison at

YASF

Yet another syndication format, necho 0.1, has been introduced by Sam Ruby and gang. Sam offered a preliminary spec for the format and others are releasing feeds in this format so I'm following suit. My necho 0.1 file can be found in my list of... [more]

Trackback from Larry's Log

at

FWIW, the only required element I had trouble with was [modified].  b2 only stores one date per posting, which defaults to the original post date, but can be set to anything.  When editing an item, this date is not automatically changed.  And if it were changed, my permalinks would break, since they are date-based (/2003/7/2/blah-blah-blah).

The various date manipulations were somewhat complicated by the fact that b2 stores the date in the database as a MySQL 'datetime', in (server time zone) + (configurable adjustment factor) time zone.  I find working with those clumsy.

I was also pulling my hair out because PHP's sprintf suddenly decided to append ASCII NUL characters to all my strings, which were actually printed out when those strings were 'echo'ed, which results in invisibly non-well formed XML.  What's up with that?  Only 'curl [my-necho-feed] | cat -nvet' revealed the problem.  I abandoned sprintf and wrote my own, probably buggy, code to format the time zone with signs and leading zeroes.

Posted by steve minutillo at

The Verbosity of Echo

Sam Ruby has called for people to start experimenting with the current (very early) Echo example feeds, and the response has been pretty impressive; check out these feeds from Joel Spolsky, Phil Ringnalda and Mark Pilgrim. Now that Echo has ...

Pingback from Simon Willison: The Verbosity of Echo

at

RSS to Necho Converter

Updated my Rss to Necho converter. Remember that everything is subject to change. You can see other Necho tools on Sam's blog. Here's how you can add Necho to your own website using my translator. So you wanna be an early adopter of Echo ? Add...

Excerpt from iBLOGthere4iM at

Are we not going to have any source of resource id?  Something that fulfills the role of rdf:about and rdf:resource in RSS?

It's very useful when marking up intra-entry relationships (i.e. comments), and equally useful for the purpose of identifying separate entries when aggregating.

Posted by kellan at

I've removed the created and issued tags from my feed as suggested. Those were in the example at 11:00 pm last night but they disappeared by this morning :)

The "maximal example" doc says really clearly, "All dates are W3CDTF". W3CDTF explicitly allows me to use my own time zone. So I'm going to keep doing that until somebody shows me why I shouldn't.

Posted by Joel Spolsky at

Echo Enabled

Sam Ruby invites development of prototype Echo feeds, so frejol.org now has a test (n)echo feed...... [more]

Trackback from nick boalch : log

at

Well, blojsom (or rather my blog) is now generating necho 0.1 feeds. Here is the feed. Some blojsom-specific thoughts and the current template can be found in this entry. Those are just thoughts on how some optional elements might be supported in blojsom. Changes to the feed will probably occur on a weekly basis as the specification evolves.

It might not be <aerosmith>living on the edge</aerosmith>, but it's a living :)

Posted by David Czarnecki at

There appeared to be some consensus on not using <weblog> (with AaronSW dissenting) and using <url role="?"> instead.

<weblog> really doesn't make sense for BBC feeds, for example.

Posted by Mark "Hex" Hershberger at

Following recent updates to the content page about site summaries vs. syndication, I've created two feeds, one as metadata (site summary) and one as syndication (embedded content):

  http://bitsko.slc.ut.us/blog/index.site
  http://bitsko.slc.ut.us/blog/index.necho

Posted by Ken MacLeod at

The email element should be added to the author elements, if this is a "maximal" feed.  It was in the author page on the wiki, but never made it over to the example feeds.

Can you add it to your samples, Sam?

Posted by Greg Reinacker at

Sam, the feed looks good. I would make the following comments:
<ul><li>The content discussion is divided over the issue of multiple content elements, but the snapshot already shows multiple content elements. Should the content discussion be deprecated in relation to the number of elements?
<li>the comments/entry discussion seems to be reaching consensus. If the end result is "comments are entries", an additional element "parent-id" should probably be added to the entries. The comment discussion would then flow back up into the main feed elements discussion (inline entries or flat structure, etc). In any case, as the main elements "stabilize" the discussion on how comments are handled should move up into the main trunk I think, since it will probably affect it, and it would get more people involved in it, which is always good. :)
</ul>
And, thanks for your efforts. Necho is coming along nicely and your stewardship of the process has made a huge difference in my opinion.

Posted by Diego Doval at

Oops, I got carried away and in my previous comment I added HTML tags that weren't allows (LI, UL). Sorry. :)

Posted by Diego Doval at

I updated the wiki example with an email address in the author...

Posted by Greg Reinacker at

Quick Links - 2003 07 02

Last update: 02/07/03; 13:12:39 EDT Scripting, Blogging, Softwares... Brent Simmons : Blogger: We are moving away from XML-RPC : The Blogger folks continue: "If you choose to take advantage of the capabilities of the new API, you will need to use...

Excerpt from blog.scriptdigital.com at

I am missing an image or logo element. Both in the RSS readers and in my (IE4 CDF revival) it is quit usefule to distinguish the feed visuallly.

Isn't it better to discuss a bit loanger as now the empale feeds look really pathetic compared to RRS 2.0 and RDF-RSS 1.0.

A few perfectly good element names channel, item, description were changed in feed, entry and summary, big dela.

Some elements are not in like category, image...

A Useless new sub-title element is introduced.

Boys and Girls what are we doing. Isn't it time we get some more rational experienced people into this to see what is really needed.

A maximal example, come on.
We need to do alot better otherwise better fiddle a bit more with RSS 2.0 and include some needed items with a namespace.

Cybarber

Posted by cybarber at

A long time coming

Necho seems to be happening. If a workable, supportable format comes out of this I will support it in BlogWorks. Although BlogWorks does, by default attempt to put out valid (x)HTML it's still too easy to screw it up - this is one of the reasons...

Excerpt from xasperate.com at

Necho in Dublin Core and Funky RSS2.

Sam Ruby posts an initial prototype of (N)echo. This all seems like a rather silly reinvention of the wheel though as it has not incorporated sound elements of prior art. I've created three prototype MT templates for producing the conceptual Necho... [more]

Trackback from tima thinking outloud.

at

Re: bandwidth use

I think Simon has a point here. It's getting a bit verbose, and I know for one thing that I choose to use RSS 0.91 because it was just simple, didn't need too much stuff. Keep It Simple Stupid! Having some optional tags really doesn't make it too hard to parse, in my opinion.

The whole publisher, editor, graphics-guy thingie should probably be done in an extension (ie in another namespace).

Also, the <url role=""> seems to be an improvement to me.

Posted by Manuzhai at

I'm impressed how simple it is to take the code to produce an RSS1.0 feed and cloning it to produce a Necho 0.1 feed (grabbed from Mark Pilgrim's feed example above). I've done this with my blog already (Yeah, I know there'll be changes - but what the hell *g*). I'm using PHP and templates.
PHP template file: http://www.isolani.co.uk/isoBlog/isolani.necho

http://www.isolani.co.uk/blog/index.necho is the main one, plus I have ones for all the channels. Links at the bottom of my blog page. (Oh, I cloned a quick Necho0.1 button image for my blog feed links, please feel free to grab it and reuse)

Posted by Isofarro at

Simon Willison writes:

I've implemented conditional GET on [my RSS feed], but it is still a
huge bandwidth hog as every subscriber sucks down the whole feed
every time I post an update (and I frequently post several updates a
day).

What percentage of clients use conditional GET requests?

[A]n optimisation for Necho feeds that eliminates the need for
duplicated author information in every entry, described here:
http://intertwingly.net/wiki/pie/EchoFeedWithAuthorRefs

IMHO, author information should only be referred to by URI.

Posted by Arien at

I'd change a few things:

And add these:

I really think too many elements are required at the moment, leading to a feed which is rather verbose.

I'm inexperienced in the world of feeds/RSS etc, so forgive me if I'm talking nonsense.

For the record, I think Necho isn't brilliant, but then I always thought Yahoo! was pretty stupid, so what do I know?

Posted by Simon Jessey at

Mark comments on "Echo chamber"

Here's a first draft: http://www.intertwingly.net/blog/1506.html...

Excerpt from dive into mark at

Mark comments on "Will the real RSS validator please stand up?"

Actually, I believe (not-)Echo will have a required permalink element. http://www.intertwingly.net/blog/1506.html...

Excerpt from dive into mark at

Here's my Blosxom-based feed [http://www.raelity.org/archives/index.necho].  I'll be pulling together a publicly-available necho Blosxom module and flavour templates for all to fiddle with.

Posted by Rael Dornfest at

Greg Reinacker writes:

The email element should be added to the author elements, if this is
a "maximal" feed.  It was in the author page on the wiki, but never
made it over to the example feeds.

The name is (again) unnecessarily restrictive: there are more URI schemes that could do as content/value here. IMHO, "contact" (or some such) would be more appropriate.

But then again, this sort of information shouldn't be be part of a feed.

Posted by Arien at

Here's a stab at it from me:-

http://jessey.net/blog/necho.xml

I don't like the idea of dumping an entire entry into a block of CDATA. I want my punters to visit my actual weblog, so a summary seems more apt.

Posted by Simon Jessey at

Oops. I've just noticed there IS a content element for entry. Sorry for the confusion.

Posted by Simon Jessey at

Necho 0.1

Sembla que ara Echo (abans Pie) es diu Necho. La discussi&#243; i la definici&#243; de l'est&#224;ndard progressen r&#224;pidament. Es veu que hi ha inter&#232;s en el tema. By Sam Ruby: necho 0.1....... [more]

Trackback from Sierto

at

Necho on the Rise

A lot of Necho feeds coming out of the bushes. Great stuff! Many of them are bad and good from moment to moment, but you'll get an idea of what is coming. I've noticed a lot of non-well-formed XML. Still :( This usually indicates that the developer...

Excerpt from iBLOGthere4iM at

Necho 0.1 Feed

I've gone ahead and started fiddling with a Blosxom plug-in and flavour templates for an outgoing NECHO 0.1 feed. Here it is. I'll be making an initial necho plug-in and flavour template bundle available for all Blosxom users shortly. ...

Excerpt from raelity bytes at

(I didn't know where else to post this, so I'm sorry if I'm spamming your comments)

Holy cow but you guys are going to get creamed when some commercial content management system decides on a syndication spec to give to all of its customers.  I see Vignette coming along and blowing you guys away with a flick of their wrist.

You must, must, must (I can't emphasize this enough) include some sort of authorization/encryption/challenge-response format for individual feeds, at the very least.  Content syndication, at least at the corporate level, must take place within a secure environment, and I don't mean just slapping on SSL to a feed reader and calling it a day.  Every single piece of data should have the ability to be encrypted in any number of formats, whether 3DES, Blowfish, RSA, PGP, etc.  Companies will demand at least this level of security before they use your solution to syndicate content.

You must, must, must (again, I can't emphasize this enough) create some sort of delta feed, to be able to tell what is new in your data stream without having to download 100k+ of a syndication datafile.  Imagine a feed with 100,000 subscribers, each subscriber doing a refresh every ten minutes, having to download 100k.  You're transferring 10GB of traffic every ten minutes.  That sounds an awful lot like a reverse-Marimba to me.  If you had a very-stripped-down feed that showed the deltas in your data within the last, say, (user-mandated time period), you're going to incur much less traffic.

You must, must, must (this sounds repetitive) allow for in-line data, whether encoded as Base64 or otherwise, and filtered, variable based upon the client.  Static files are great, if you live in the year 1994.  You may argue "that's up to the software to determine" but I would say: what of JavaScript?  Here is a language that determines the format of the HTML page being displayed, based in part on the client.  As an aside, allow for device detection as part of the feed.  My cellphone must absolutely get a different version of the feed than my newsreader.  In-line HTML is worthless to a cellphone.

These may be fairly ignorant statements-- you may have already covered all of these points, or you may just push all of these ideas off on the Ben Trotts of the world who get to go through the hell of implementation.  I'm looking at RSS as an end-user and I
see this group going down the same path, making the same mistakes, that RSS made.  This format should be an evolution from RSS, not a duplication.  Imagine how CSS and the DOM has changed web development versus the year 1997 when we were struggling with embedded tables.

Thanks for reading my rant.

Posted by Mark Beeson at

interesting rant.  However, there is nothing in the existing format which forbids the extensions you talk about, nor is there anything which mandates the use of static files, nor is there anything which suggests that the content will not be a delta.

Posted by Felix at

Mark,
I think you have valid concerns (security, bandwidth), but they are outside the scope of the core spec. How a particular implementation decides to secure, encrypt, or produce its feed is entirely up to it. If you are going to encrypt something, encrypt the entire feed from beginning to end and have the receiving client decrypt it. Currently, I am not aware of any aggregator that does this, so you'd be rolling your own solution from back to front.

We're trying to design a file/message format that utilizes the best features of previous formats while overcoming their limitations. The scope of this project is to learn from the mistakes of previous implementations and unify APIs that have evolved independently but which all do the same thing.

We're not in the CMS business, and Vignette is welcome to extend this format, as is anyone else. We're just doing this 'cause we love the technology.

Posted by Christian Romney at

The Syndication Format Not Known As Echo

Following the news of Sam Ruby’s snapshot spec, here’s my first pass at a newsfeed in the format that will not be known as Echo. This is, of course, a largely theoretical exercise, because, to my knowledge, there are no aggregators yet...

Excerpt from freeform goodness at

"We're not in the CMS business"

I disagree entirely.  Movable Type is a CMS.  Blogger is a CMS.  Radio is a CMS.  Unless you feel that weblogs aren't content?

Encrypting the entire feed isn't a viable option, in my opinion.  Some clients should be allowed to see some data, while others should be allowed to see other data.  For instance, I may pay Reuters a certain amount per month for a "base" syndication feed.  You may pay Reuters a larger amount of money for a "deluxe" syndication feed.  How do you distinguish between our levels of syndication?  Generating separate XML files per client doesn't count; that defeats purpose of easy-to-use syndication.

I would ask everyone to not go into this process thinking "how can we reinvent a weblog text file format" but "how can we create a fully-functional content syndication format".  Content isn't only text from a weblog.

"Start lightweight and tack on extensions" is a good mantra only if the base format can handle the extensions being tacked on.  Challenge everything.  Is the "one text file" format sufficient?  Is the "plaintext published by weblog utility" way of thinking sufficient?

One thing I neglected to mention: I haven't seen any sort of thought being given to content expiration, either.  You may say "content doesn't expire, and shouldn't" but I refer you back to my example: if I pay for a weekly syndication, and you pay for a monthly syndication, how does a company tell me when to remove the data I've syndicated?

Thanks again.

Posted by Mark Beeson at

Mark:

<weblog> really doesn't make sense for BBC feeds, for example.

Nor should it. I'd encourage people to have another look at the roadmap... Echo is supposed to be a weblog-centric format. The BBC will and should continue to use more generic syndication formats like RSS.

I have a sneaky suspicion that somewhere in the depths of the wiki, many people are forgetting this little detail. I hope someone reminds them ASAP.

Posted by Roger Benningfield at

Mark Beeson:

You may pay Reuters a larger amount of money for a "deluxe" syndication feed.  How do you distinguish between our levels of syndication?  Generating separate XML files per client doesn't count; that defeats purpose of easy-to-use syndication.

Mark, try reading that again a couple times. You want support for per-item encryption and multiple levels of subscription, but you're concerned that multiple XML files aren't easy to use? :)

I would ask everyone to not go into this process thinking "how can we reinvent a weblog text file format" but "how can we create a fully-functional content syndication format".

See the roadmap. Echo is a thing for weblogs.

Posted by Roger Benningfield at

Actually its seems it would be the opposite way around:

Anatomy of a Well Formed Log Entry
http://www.intertwingly.net/blog/1472.html

Noticed in Sam's announcement he does not use the word weblog once. He carefully used the word log NOT weblog.

Someone superimposed weblog along the line. I have been working under the impression that this syntax goes beyond weblogs.

I see no reason why this syntax is not applicable to a newsfeed.

Posted by Timothy Appnel at

"...but you're concerned that multiple XML files aren't easy to use?"

Yes.  Do you want to generate 100,000 XML files, for 100,000 paying subscribers?  I have a sneaking suspicion that scalability isn't really being taken into consideration here.  Again, I would beg of everyone to not push that sort of functionality onto the software developers, because then we'll all be duplicating work that can be easily taken care of with a robust syndication format.

I'm also hearing that this is solely for weblogs.  I find that to be an incredibly short-sighted vision.  Design a good format, and weblogs will use it.  Design a great format, and everyone will use it.

Posted by Mark Beeson at

Timothy: a bit of historical triva.  The reason I used 'log' instead of 'weblog' was for the acronym that the title would generate.

Posted by Sam Ruby at

Mark:

In a previous life, I worked for a major search engine. We served well over 100,000 dynamically generated search result pages per day; although I'm not sure of the numbers, we may have done that many XML pages for paying customers. It wasn't all that hard.

I may well be missing something that makes this a bigger scaling problem -- comments?

Posted by Bryant at

Updating 100,000 files sitting on a filesystem (whether sitting on a NAS or spread across machines) is not nearly as easy a chore as updating 100,000 rows in a table.  There are all sorts of implementation pitfalls when you get to that level of service.  What happens when you update 50 times daily?  Do you update 100,000 files 50 times?  50 million file updates in a day?  I can hear drive heads everywhere crying out for mercy.

Posted by Mark Beeson at

OK, I must be getting dense here. Why are you writing the XML to a file, rather than generating it on the fly?

Posted by Bryant at

... for that matter, 50 million file updates in a day is not so very terrible. I'm not saying it's not challenging, and I think I'd rather tackle the dynamic generation problem, but logging > 50,000,000 Web hits per day didn't kill us either.

Posted by Bryant at

Here is my first crack at the syndication format formerly known as echo: http://aspnetweblog.com/necho.aspx

Posted by Scott Watermasysk at

The new syndicataion format

After a vacation, some travel and relaxation, I think I'm willing to jump back into the fray. I have an necho feed. Source is available. I've also started hacking at Mark's Ultra-Liberal RSS parser to create a necho parser. Thats all for tonight, I... [more]

Trackback from john.beimler

at

Timothy:

Noticed in Sam's announcement he does not use the word weblog once.

I hate to be the jerk who points this kind of thing out, but he uses it right up front, in his second sentence.

"These are essential characteristics of a online Journal or weblog."

But that's beside the point, really. All those "signatures" on the roadmap page are attached to a document that makes it clear the mission here is furthering interoperation between weblogs. If other uses can be found after-the-fact or via extensions, that's great... but such uses are secondary at best.

Posted by Roger Benningfield at

Then, if the <author> is the author of the weblog, why do you need a <weblog>?

Further, the FrontPage (which is where many people start on the Wiki), states "The EchoProject is an initiative to develop a common syntax for syndication, archiving and an publishing API."

If it is a common syntax for weblog syndication, archiving, etc., then shouldn't it state that in the introductory paragraph?

Posted by Mark A. Hershberger at

I've created a somewhat "funky" example feed of how a Necho feed could be used for program listings.

The or differences from the plain-vanilla 0.1 Necho feed are:

The general idea is that a generalized Echo aggregator would provide a user with a normal program listing, while an specialized tool could read the same feed and schedule playlists. Think TiVo.

Posted by Arve Bersvendsen at

It Validates!

I just ran my necho 0.1 feed through the Userland RSS Validator and it validated. What better endorsement for necho than this?... [more]

Trackback from Larry's Log

at

The new syndicataion format

After a vacation, some travel and relaxation, I think I'm willing to jump back into the fray. I have an necho feed. Source is available. I've also started hacking at Mark's Ultra-Liberal RSS parser to create a necho parser. Thats all for tonight, I...

Excerpt from john.beimler at

Ermm... I had a little time today, so I hacked nntp//rss to handle necho 0.1 feeds - its hackerish, but seems to work okay.
http://www.isolani.co.uk/blog/semanticweb/EarlyHackingInNecho

Posted by Isofarro at

Necho Update

I'm off to walk around favorite places today, but first an update on what was Echo and now looks to become Necho by default. I tried to catch up on the wiki, but a couple of days on the road has put me hopelessly out of touch on this project.... [more]

Trackback from Burningbird

at

major BlogX refactoring underway

last night i started refactoring the BlogX Runtime assembly. i started by organizing the project into folders. some of these include DataModel, Formats, Logging, FTP, and Links. next, I broke out files which had tons of classes in them. each class,... [more]

Trackback from romney.blog: daring to write code and chronicle the mundane

at

Necho to RSS converter

New Necho to Rss converter. Remember that everything is subject to change. You can see other Necho tools on Sam's blog. Here's how you can convert an Echo feed to RSS and use it in any News Aggregator. You can now convert your Echo to RSS. Just...

Excerpt from iBLOGthere4iM at

Other things

My latest XML.com article tackles images in XHTML 2.  My Safari bug list is up-to-date with Safari 1.0.  Sam has an early prototype of a (not-)Echo syndication feed, and I have a Movable Type template to match it.... [more]

Trackback from dive into mark

at

Nechophila

In which Aquarion supports a format that&#8217;s more UnAlive than Undead... [more]

Trackback from Aquarionics

at

Mark writes:
"Do you want to generate 100,000 XML files, for 100,000 paying subscribers?
  I have a sneaking suspicion that scalability isn't really being taken into consideration here.  Again, I would beg of everyone to not push that sort of functionality onto the software developers, because then we'll all be duplicating work that can be easily taken care of with a robust syndication format."

1) There's nothing about forced serialization to disk in the spec.  All of that XML is just rows in a table until it's serialized out to RAM.

2) You can encrypt your entries how you like, using CDATA.  Knock yourself out with that crazy DRM action too, while you're at it.  Add all the timeout attributes you feel like.

Not to be rude, but you clearly haven't thought this one through.  Extras used by .0001% of the clientele (less, but I'm being charitable), like encryption (!!) or DRM (!!!!) are perfect candidates for external modules.  I can't wait to be able to send people embedded perl fragments for them to auto-execute, but you won't see me put that in the wiki.

Disclaimer: I once stayed over for a weekend at Bryant's house -- my ideas are his, and only his.

Posted by Felix at

I'm confused, and it surely comes from not ready carefully enough, but there are a whole lot of places to be reading to keep up to date on this these days.

Will the new format allow for full content to be included?  Sam's list of <entry> specs at the top of this page doesn't include any reference to the body, the meat, the full content.  I'd presume there's at least a 50-50 split of end-user preference for descriptions vs. full content.

Posted by Lex at

Lex: yes.

I also think you're right about a near even split.  I don't know if there will be different profiles for each, or if the separating of "description" into "summary" and "content" solves the problem neatly.

Posted by Ken MacLeod at

Burningbird burns one.....

Necho Update. I'm off to walk around favorite places today, but first an update on what was Echo and now looks to become Necho by default. I tried to catch up on the wiki, but a couple of days on the road has put me hopelessly out of touch on this...

Excerpt from Marc's Voice at

Burningbird burns one.....

  Burningbird burns one..... Burningbird burns one...... Necho Update. I'm off to walk around favorite places today, but first an update on what was Echo and now looks to become Necho by default. I tried to catch up on the wiki, but a couple of...

Excerpt from Audioblog/Mobileblogging News at

Martin,

I think at a minimum, supporting existing categories (by name) should be supported (as an optional 1+ attribute).  As you mentioned, these would be feed-specific.

But I think your idea of using a URI, so as to fit in some sort of "shared" categorization makes sense, too.  Perhaps supporting both, through an attribute, uri=true or somesuch...  Of course, with URIs there's the problem of what to name these things in the client app.

Looking at the example again, I hadn't realized that there's already been some work going on in this area, "Easy News Topics"  See http://matt.blogs.it/specs/ENT/1.0/

Maybe that can be used directly, as an extension to necho.  Dunno.  Sifry has a little analysis of this idea here: http://www.sifry.com/alerts/archives/000282.html

Posted by Chris Wilper at

NECHO conversion to CDF RSS1/2 to CDF and RSS2 to RDF)

I had put a message in the well-formed XHTML group but here is more appropiate.

Based on Yasser Shohoud's and Sjoerd Visscher(unchanged) XSLT sheets, I made a demo page.

Showing how I work with the ancient IE4 Channel Definition File(CDF) format under WIndows XP proff.

I have uploaded Sopolsky's, Pilgrim's, Watermasysk's, Burton's, Isolani, Bersvendsen and the Maximumtemplate itself to my site.

For transformation I changed  the encodings to utf-8 and deleted the namespace references.

In the demo page  above necho-files can be selected in the Selectbox and transformed to CDF. transform to RSS2.0 and RDF(Rss1.0) I'll do this weekend. (page starts with a SMIL animation showing an image of Sam Ruby's RSS feed in CDF on my PC, you need IE55/IE6 msxml3.0)

http://cybarber.ath.cx/kanaal/TestingwithSources.htm
Cybarber

Posted by cybarber at

NEW name for non-Echo.
As we will not use 'ECHO' nor 'NECHO', I propose the following name for the new RSS-XML vocabulary:

Synchronized Aggregated Messaging

or for short

SAM

This will give at the same time credit to the big motor behind all this Sam Ruby

My SAM to CDF and tomorro my SAM to RSS2 demo page is online at:

http://cybarber.ath.cx/TestingwithSources.htm

Cybarber

Posted by cybarber at

The Syndication Format Not Known As Echo

Following the news of Sam Ruby’s snapshot spec, here’s my first pass at a newsfeed in the format that will not be known as Echo. This is, of course, a largely theoretical exercise, because, to my knowledge, there are no aggregators yet...

Excerpt from freeform goodness at

Name Proposal for not-Echo
updated proposal

I'll stick with

SAM

but I was pointed out that is better to use Syndication(ed) instead of Synchronized. Instead of Messaging maybe Markup is better,
so

S(yndication) A(ggregation) M(arkup)

Cybarber

Posted by Cybarber at

Echo assumptions

Sam Ruby: necho 0.1 Add namespaces to those assumptions.... [more]

Trackback from Bill de hÓra

at

Updated n-Echo Prototype

After combining work of a number of different people (particularly Mark Pilgrim and Chris Wilpin, I have produced a MovableType template that meets Sam Ruby's snapshot spec for n-Echo 0.1 for all but two (optional) elements. Read more for the geeky... [more]

Trackback from Dan Dickinson: The Primary Vivid Weblog

at

Straw as a Necho Aggregator

As everyone knows who's read the about page,
this site uses weblog technology to do its magic.  Weblog technology is
moving very quickly at the moment, and there's
a new effort
out there to more clearly define what it's... [more]

Trackback from Licquia.org: Jeff's Log

at

(SOURCE:Sam Ruby)-And so it begins. Necho = new name for Echo = new kind of RSS. Implementations have begun to spill forth. Waiting for the dust to settle before adopting this! <QUOTE> I've taken a 2003/07/01 snapshot of the maximal example of...

Excerpt from Roland Tanglao's Weblog at

Date & Time Format

We admire the conformance to the ISO 8601 standard, but would appreciate it if the time zone would remain optional, consistent and preferably based on the posters local time zone (oh and no shortcuts, always as +00:00).

Thanks and good luck,

@Quest WebDesign http://www.atQuest.nl/



Emailed by Pallieter Koopmans at

I've added support for (not)Echo to BottomFeeder - http://www.cincomsmalltalk.com/BottomFeeder.  I've also added not Echo formatted feeds for my blog:

blog: http://www.cincomsmalltalk.com/blog/blogView

feed: http://www.cincomsmalltalk.com/rssBlog/necho.xml
comment feed: http://www.cincomsmalltalk.com/rssBlog/nechoComments.xml

Message from James Robertson at

I've added support for (not)Echo to BottomFeeder - http://www.cincomsmalltalk.com/BottomFeeder.  I've also added not Echo formatted feeds for my blog:

blog: http://www.cincomsmalltalk.com/blog/blogView

feed: http://www.cincomsmalltalk.com/rssBlog/necho.xml
comment feed: http://www.cincomsmalltalk.com/rssBlog/nechoComments.xml

Posted by James Robertson at

Here's mine: http://www.gnome.org/~jdub/?flav=necho

Posted by Jeff Waugh at

First attempt, using my home-brewed publishing system: http://rasterweb.net/raster/necho.xml

Posted by Pete Prodoehl at

I have cooked up a formatDriver for necho in Radio Userland.

http://www.brainoff.com/necho/

Posted by Mikel Maron at

sam ruby: necho 0.1

sam ruby: necho 0.1... [more]

Trackback from WE ARE HUGH

at

Schemaware for Pie 0.1

I cooked up a RelaxNG schema for Pie/Not-Echo or whatever you want to call it, in its 0.1 snapshot form. Which, as a side-effect, generates a W3C XML Schema. This note includes specific conmmentary on this schema, general commentary on schemas...

Excerpt from ongoing at

Preliminary Pie support

The validator is now known as the "Feed Validator", because it now supports multiple syndication formats with different names. (Previously it only supported the seven different formats called "RSS".) Specifically, there is now preliminary support...

Excerpt from Feed Validator News at

Feed Validator: Now With Pie

Here's an update from the validator formerly known as the RSS Validator and now known as the Feed Validator: The validator is now known as the "Feed Validator", because it now supports multiple syndication formats with different names. (Previously...

Excerpt from Matt Croydon: Python at

Ultra Liberal Feed Parser

Mark Pilgrim has added support for the 7/1/03 snapshot of the format that shall not be called echo in his latest version of his now ultra-liberal feed parser: Handles RSS 0.9x, RSS 1.0, RSS 2.0, Pie feeds You may now commence your consumption of...

Excerpt from Matt Croydon: Python at

Feed Validator: Now With Pie

Here's an update from the validator formerly known as the RSS Validator and now known as the Feed Validator: The validator is now known as the "Feed Validator", because it now supports multiple syndication formats with different names. (Previously...

Excerpt from Matt Croydon: Weblogs at

Ultra Liberal Feed Parser

Mark Pilgrim has added support for the 7/1/03 snapshot of the format that shall not be called echo in his latest version of his now ultra-liberal feed parser: Handles RSS 0.9x, RSS 1.0, RSS 2.0, Pie feeds You may now commence your consumption of...

Excerpt from Matt Croydon: Weblogs at

Feed Validator: Now With Pie

Here's an update from the validator formerly known as the RSS Validator and now known as the Feed Validator: The validator is now known as the "Feed Validator", because it now supports multiple syndication formats with different names. (Previously...

Excerpt from Matt Croydon::postneo at

Ultra Liberal Feed Parser

Mark Pilgrim has added support for the 7/1/03 snapshot of the format that shall not be called echo in his latest version of his now ultra-liberal feed parser: Handles RSS 0.9x, RSS 1.0, RSS 2.0, Pie feeds You may now commence your consumption of...

Excerpt from Matt Croydon::postneo at

Ultra Liberal Feed Parser. Mark Pilgrim has added support for the 7/1/03 snapshot of the format that shall not be called echo in his latest version of his now ultra-liberal feed parser: Handles RSS 0.9x, RSS 1.0, RSS 2.0, Pie feeds You may now...

Excerpt from Brett Morgan's <Strike>Insanity Weblog</Strike> Zilla at

Experimental (N)Echo feed

I have just added a new feed based on the evolving (N)Echo effort. The template cames from Dan Dickinson, which was pointed to by Werner Vogels....... [more]

Trackback from Dave Seidel :: Wavicle

at

Pie progress report

Echo API draft 3 is out.  The validator now validates feeds in the new format, and my ultra-liberal parser now parses them.... [more]

Trackback from dive into mark

at

Recent Changes

(2003-07-12:12:30+01:00) Necho and MetaPub appear to be the current front-runners in ProjectNameProposals. Suggestions that there is WikiChaos suggest that those who know the answers maybe should take a break from expressing them and do a bit of...

Excerpt from Formerly Echo at

Experimental not-Echo

I've added a highly experimental not-Echo feed. It is a unified feed that contains both entries, comments and trackbacks. Instead...... [more]

Trackback from Virtuelvis

at

Schema for Echo

Tim Bray writes: I cooked up a RelaxNG schema for Pie/Not-Echo or whatever you want to call it, in its 0.1 snapshot form. Which, as a side-effect, generates a W3C XML Schema. [ Tim Bray - Schemaware for Pie 0.1 ] The schema generated from the...

Excerpt from TheArchitect.co.uk - Jorgen Thelin's weblog at

Echo feed for this blog?

I think I can create an Echo feed. Looking at how MovableType handles construction of its RDF feeds I should be able to do it - lets just hope MovableTyps tags provide enough information. If its as easy as I...... [more]

Trackback from magpiebrain

at

(N)Echo Template for MovableType

Before I started working on the aforementioned template for (N)Echo 0.1, I thought I'd better check to see if anyone else has done it. Sure enough I came across a template by Dan Dickinson. His template requires the use of...... [more]

Trackback from magpiebrain

at

xmlns strikes again

<p>I've been thinking about Sam's suggestion for how to provide unencoded content in my atom feed, in looking at his example, I spotted one problem, the second content entry, which is an unencoded text/html part has the html tags in the atom... [more]

Trackback from Simon Fell > Its just code

at

The day the blogging died

A terrible parody of American Pie (the song, not the movie), now with hyperlinks!... [more]

Trackback from Radio Free Blogistan

at

Wenn der Sommer schon fast vorbei ist ...

<P dir=ltr>This made my day (<A href="http://www.writers.net/forum/read/1/10812/10809Vf">frei nach Clint Eastwood</A>).</P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P><A... [more]

Trackback from thomas n. burg | randgänge

at

Mark, thanks for the Radio bug report. The bug has been fixed.

Note that this bug affected only outbound pings from Radio, and not pings from Manila.

Posted by Jake Savin at

Thanks Jake.  Glad to hear it was just a bug, and that it's fixed.

Posted by Mark at

Mark, thanks for the Radio bug report. The bug has been fixed.

Note that this bug affected only outbound pings from Radio, and not pings from Manila.

Jake: excellent responsiveness, as always.  Bravo.

Having let my Radio subscription expire, I am not in a position to test this for myself.  Perhaps you might want to ping this entry to see if my implementation of trackback interoperates with the updated Radio?

Posted by Sam Ruby at

Mark Pilgrim's bug report. Just a bug, not a conspiracy....

Excerpt from Scripting News at

The day the blogging died http://radiofreeblogistan.com/2003/07/31/the_day_the_blogging_died.html Blogistan PieA long, long time agoI can still rememberHow those weblogs used to make me smile And I knew if I had my chanceI could make the...

Excerpt from WIFLblog at

The day the blogging died http://radiofreeblogistan.com/2003/07/31/the_day_the_blogging_died.html Blogistan PieA long, long time agoI can still rememberHow those weblogs used to make me smile And I knew if I had my chanceI could make the...

Excerpt from Ted Ritzer: RSS at

The day the blogging died http://radiofreeblogistan.com/2003/07/31/the_day_the_blogging_died.html Blogistan PieA long, long time agoI can still rememberHow those weblogs used to make me smile And I knew if I had my chanceI could make the...

Excerpt from Ted Ritzer: Free Music at

The day the blogging died http://radiofreeblogistan.com/2003/07/31/the_day_the_blogging_died.html Blogistan PieA long, long time agoI can still rememberHow those weblogs used to make me smile And I knew if I had my chanceI could make the...

Excerpt from Ted Ritzer: Gotta Try or Visit at

Das machte auch meinen Tag

And they where singing Bye bye wiki necho or pie Took my standard to a body But the body had died And the good ol' boys Drinking kool-aid and lies Singing this is the day blogging died. Radio Free Blogistan: Bloggistan Pie....

Excerpt from Der Schockwellenreiter at

The day the blogging died http://radiofreeblogistan.com/2003/07/31/the_day_the_blogging_died.html Blogistan PieA long, long time agoI can still rememberHow those weblogs used to make me smile And I knew if I had my chanceI could make the...

Excerpt from Ted Ritzer: BizBlog at

The day the blogging died http://radiofreeblogistan.com/2003/07/31/the_day_the_blogging_died.html Blogistan PieA long, long time agoI can still rememberHow those weblogs used to make me smile And I knew if I had my chanceI could make the...

Excerpt from Ted Ritzer: NetMedia at

Necho 0.1 Feed

I've gone ahead and started fiddling with a Blosxom plug-in and flavour templates for an outgoing NECHO 0......

Excerpt from raelity bytes at

(SOURCE:"sam ruby")- And so it begins.... [more]

Trackback from Roland Tanglao's Weblog

at

Preliminary Pie support

The validator is now known as the "Feed Validator", because it now supports multiple syndication formats with different names. (Previously it only supported the seven different formats called "RSS".) Specifically, there is now preliminary support...

Excerpt from Feed Validator News at

[CSS] border-radius

border-radiusという属性があるようだ。epiphanyでも正しく反映されているようだ。 サンプルページ:http://www.intertwingly.net/blog/1506.html...

Excerpt from IWS's Weblog Site : at

(N)Echo Template for MovableType

Before I started working on the aforementioned template for (N)Echo 0.1, I thought I’d better check to see if anyone else has done it. Sure enough I came across a template by Dan Dickinson. His template requires the use of a couple of MT...

Excerpt from magpiebrain: (N)Echo Template for MovableType at

Add your comment