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
title: required, plaintext
subtitle: required, plaintext
link: required, URI
modified: optional, dateTime, UTC preferred
entry, zeroOrMore
Entry elements
title: required, plaintext. May be zero length
subtitle: optional, plaintext
summary: optional, plaintext
author: required
contributor: zeroOrMore
link: required, URI
id: required, URI
created: optional, dateTime, UTC preferred
issued: required, dateTime, local timezone preferred
modified: required, dateTime, UTC preferred
Feel free to challenge these assumptions... they are not cast in
stone.
- 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">?
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.
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.
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.)
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?
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
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
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>
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.
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.
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]
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.
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. ...
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.
* 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).
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.
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)
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.
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).
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.
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.
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]
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.
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 ...
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...
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.
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.
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 :)
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):
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.
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.
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...
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...
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]
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.
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)
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?
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.
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.
Sembla que ara Echo (abans Pie) es diu Necho. La discussió i la definició de l'estàndard progressen ràpidament. Es veu que hi ha interès en el tema. By Sam Ruby: necho 0.1.......
[more]
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...
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. ...
(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.
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.
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.
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...
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?
<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.
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".
"...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.
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?
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.
... 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.
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]
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.
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?
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:
Uses <href> instead of <homepage> for the <author>. Homepage seems somewhat inappropriate for an organization.
The <valid> element specifies for which time interval a resource is available.
No <content> The content is the <link>, in this case to a 128kbps MP3 feed, <summary> is used to provide a brief description.
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.
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...
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]
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]
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...
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]
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.
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.
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.
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...
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...
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/
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)
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...
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]
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]
(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...
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).
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...
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...
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...
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...
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...
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...
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...
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...
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...
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]
(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...
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...
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]
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]
<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]
<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]
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?
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...
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...
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...
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...
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....
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...
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...
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...
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...