Mon 02 Jun 2003

Sam you just changed something on your website with fonts that makes it very difficult for me to read, but I'll persevere.

To answer the question -- the PSS format, since it's designed to be included in other formats, doesn't need namespaces. In any case it's a mythological format, I think the second approach is the right one, and the first should only be pursued if the second doesn't work out.

With RSS 2.0 in mind, I asked the denizens of [xml-dev] for their opinion on the use of an optional namespace for a vocabulary, that is, define a namespace to be used when the format is embedded, but not if it is a standalone document.
This would have the advantage that current RSS 2.0 documents would all be valid, but Sam gets his namespace for when he embeds RSS 2.0 in SOAP.

Portable and Simple Syndication

Like totally cool! This is exactly what we need. RSS 2.0 still exist as is, but we can use PSS in other XML applications. But I'd also vote for taking PSS to the file level. I don't quite understand Dave's comment about less namespaces?...

Um.
According to everything I've read on namespaces, this is a really, really pointless idea.
The point of name-spaces - as I understand it - is to be able to include elements of another defined XML Schema into the current one, by defining at the top of the page what it is (foo="http://path/to/spec") where foo is whatever you want to call the namespace in this document and /path/to/spec is the canatonical reference for said spec.
Surely, all we need to do is actually support XML namespaces properly, meaning that it doesn't matter what namespace you use, providing you point to the right specifiction.

PSS and the PotatoHead Syndrome

[Dave Winer via Sam Ruby] "...invent a new format called, say, PSS, where the P stands for Portable. We can discuss what the S and S stand for (I think Simple and Syndication, but ymmv). The definition of the format is as follows: PSS is RSS 2.0...

In reading Dave Winer's proposal, he seems to prefer just adding a namespace to RSS 2.0 over creating a new PSS namespace. This also seems to be what most of the people with negative comments about his proposal want. If this is the case, why all the criticism of the PSS portion of his post instead of concentrating on the positive? What am I missing?

To Christian,
I think and hope that everybody came to realize that a new divergent RSS would not be a good idea. Eventually, that discussion went this path and I think found it to be a dead end.
To James Snell,
I agree, #1, 2 and 3.

A profile is a restricted subset of a specification. It is not "new divergent." There was nothing new about the profile being discussed other. It was shaping up to be the codification of best practices that where commonly used and preferred over other uses/misuses.

I also do not believe the discussion ended because it was not "a good idea" either. I think everyone interested in being heard voiced their opinion. I got a general sense of agreement on a lot of items. What was absent in continuing the conversation was a new draft of the profile. I don't know why Don did not release another.

Tue 03 Jun 2003

RE: PSS

Sam,
Why are you focusing on the irrelevant part of the article instead of this

The simpler way is to try an experiment with all known aggregators and feed readers (AKAFRs). Create a few sample files that have an xmlns attribute at the head of an otherwise validated RSS feed, and run them through AKAFRs and see what happens. If it works or not, make an effort to contact the developer and let them know

It seems Dave is willing to back off on his no namespaces in RSS position and instead do the right thing by encouraging developers to update their applications. If I remember correctly the last time he did this only one or two people were broken and one of them was a homegrown aggregator that wasn't in widespread use.

At one point, the Radio news aggregator accepted feeds with a global xmlns defined.

At a later point, I quietly introduced an RSS 2.1 feed. I was surprised and saddened to see that the Radio News aggregator would no longer find any items in such feeds. If somebody could check to see if this has been corrected, I would appreciate it.

If this path does not work out, I have no objections to a renaming of the protocol - I simply don't see the rationale for regressing.

Tim, as per the RSS Profile, my view was that we were not creating a subset, rather a superset. I don't see how you can include new elements, not otherwise in the spec and call it a subset.

That said, I think we should go the way of this new thread. RSS 2.0 as is with a bit of incremental functionality.

Do we consider including those new elements in the RSS profile? Maybe this is the time to validate that dc:date and dc:* are part of some RSS 2.1 or PSS 1.0. I'm not suggesting that, just THINKING OUTLOUD :)

We already went down this road. By this logic any element is thus part of RSS 2.0, so long as is part of namespace extension. So we can include pretty much any element we want in the profile now. Very convenient.

Here's what I want you all to do. Download Feedreader from feedreader.com. Now put some of your favorite feeds in there. Note that those that use the extensions look funny and those that don't, look as the author intended. The reason is that the tool author read the spec and implemented. He doesn't account for dublin core (actually he did try to account for some) because it's not in the spec. Saying that everything is in the spec because the spec is extensible, makes life impossible on the tool author.

This is a perfect demonstration of why we need a standards organization for this stuff -- ad hoc introductions of yet another new XML format for everytone to play with. But for those people who don't want to play, now they have to figure out what this other XML vocabulary is supposed to be for.

And Dare, you might want to figure out how to work with a person in a postive sense, rather than shutting people down. Otherwise all we have left is the handful of people who usually comment on these issues in these posts -- and I bet Sam would like fresh faces every once in a while. I know I would.

RSS & Namespaces

As the maintainer of the RSS backend for Gnus in Emacs (nnrss), I'll
readily admit that dealing with namespaces isn't as easy as just using
all local-names without namespaces.

Still, I can see the benefit of namespaces and nnrss has primitive
support for namespaces and some additional namespaced elements.

Why? Because those elements are widely used and, sometimes, provide
features that base RSS doesn't support.

Take <author> for example. it is "the email address of the author".
Great spam bait. Some people don't like publishing their email
address, but still want to have their name associated with the content
they produce so they use <dc:creator> which doesn't mandate including
an email address.

Why else would an RSS Profile that included namespaced elements be
useful to developers of software like nnrss and FeedReader? Because
it gives a clear target for implementation. "Support these namespaces
and elements and you've covered 80% of available feeds."

You seem to want us to stick with RSS as is (no namespaced extensions)
for the foreseeable future. Why?

(I can't download and try FeedReader since I don't have a Windows box
for testing.)

Mark, don't get me wrong. I'm completely in favor of extensions that add application functionality. For a good extension of RSS see trackback.

First, you make a good point about the SPAM. I hate SPAM more than most (200 per day). But let me suggest an alternate use of the element "nospam@kbcafe.com (Randy Morin)". This identifies the author with exposing his email address.

My feelings, overall: there have been a number of RSS specifications... in general, each has been more lax than the preceeding. The validator should provide error messages if any given element doesn't comply with the most lax definition, and warnings if the element doesn't comply with the most strict.

The reasons for dc:date are somewhat less compelling... it is easier to parse and sort and less American centric. This implies to me that the validator should have levels of strictness.

RSS Core Profile DRAFT 1

This is a slightly more formalized write-up of a proposed profile for RSS that has been discussed and brought up again. Rather then just produce an iteration of what Don Box wrote up, I thought I'd take a step back to codify some of the design...
[more]

Shelley, thanks for reminding me why I took a vacation from this scene. Yes, there are 100s of XML vocabularies -- wasn't that the point of XML, that anyone could make one? There are precious few mappings between them, although Tim among others is working on that. If we were all using RDF, there would be 100s of RDF vocabularies, and precious few mappings between them.

The RSS 2.0 Profile

This is just an empirical test of Don Box's RSS 2.0 Profile. What I'm going to do is to take Don's RSS feed and pump it into the most popular RSS news readers and give you feedback as to what you can expect if you follow the RSS 2.0 Profile. The...

The RSS 2.0 Profile

This is just an empirical test of Don Box's RSS 2.0 Profile. What I'm going to do is to take Don's RSS feed and pump it into the most popular RSS news readers and give you feedback as to what you can expect if you follow the RSS 2.0 Profile. The...

Mark Pilgrim took the words right out of my mouth. Smart guy. When XML came out, the hype was that we'd all be able to design our own vocabularies. Fool that I am I believed them, and did so. Later the W3C corrected our format and made a huge mess...

All RDF vocabularies automatically have significant mappings between them thanks to the model. That's the whole point of using RDF for exchange. XML lacks this.

re. "we can include pretty much any element we want in the profile now".
Yes, but without defining how the element should be used by an agent this doesn't give us anything. On the other hand an RDF agent can make real sense of new vocabularies thanks to the common framework.

In my view, the main benefit of using a standards body would be to establish order in an otherwise chaotic process. I am a huge fan of openness and public comment, and I do feel Sam and his readers are among the most qualified to steer this task because of their technical skill and involvement in building the very tools that consume most of the RSS being produced. Unfortunately, the strengths of the blog/comment approach to implementing a specification are also its greatest weaknesses. Perhaps I'm just a bit cynical, but it's hard to envision this as an effective medium for achieving consensus (if that is indeed the goal) on a topic that seems to be so divisive.

I readily admit that I haven't any experience in working with a standards body, so I may be completely wrong in assuming that the standards process works very slowly, but at least there is continuity in that forum. I think it is unreasonable to expect that of a blog. For example, I find it difficult to discern the current state of the development of the RSS Profile or even what its ultimate objective will be among so much dissent. Sam and Mark might have one view on this that might be distinct from Dare's, Luke's or anyone else's. My point in a nutshell: i feel this task needs 1. order and 2. an owner. Otherwise, we may find ourselves rehashing the same issues over and over while making little progress.

If you use Dublin Core for predicates in your RDF statements, and I make up a new vocabulary that includes concepts like "created by" and "has a language of" but has its own set or URIs (is not Dublin Core), you'll have no idea what my statements mean without some sort of mapping. No amount of syntax can change that.

Yes, I know there are ways of creating this mapping that are machine-readable, but the mapping has to exist, and if I was dumb enough or evil enough to create my own replacement for Dublin Core in the first place, I'm probably not smart enough or generous enough to create the mapping to Dublin Core.

Why would I do that? Evilness (attempting lock-in, even if someone else creates a mapping I can use real-world clout to ensure that most people use my ontology and not yours, and besides, people running around creating mappings to my ontologies is a good way to ensure that they're not working on anything useful). Unwillingness to play nicely with others. Ego. Ignorance. Any number of reasons.

Similarly, I can use different URIs than you to express that same subjects or objects (what's the "correct" URI for a concept like "CSS"? "Web standards"? "Truth"?) and we'll need mappings to correlate them. This first hit me when I was creating my FOAF profile (by hand, in vi, but never mind that) and wanted to list my interests. If I'm interested in Zen and you're interested in Zen but we use different URIs to express that concept, who's right? (Answer: both of us.) So how does a client know it's the same concept? A mapping. And who creates that mapping, and how do clients learn about it when neither of us includes it in our FOAF profiles?

Wed 04 Jun 2003

Christian,
Standards bodies do not add order to a chaotic process. They simply hide the chaos from you via closed mailing lists and discussion forums. Nothing stops Sam, Don et al from doing the same and simply issue forth completed documents from on high every couple of weeks until they decided their spec/profile/whatever was baked.

Of course, this would remove much of the community aspect of RSS development.

Tim, I apologise but felt obliged to respond to a comment that does nothing but reinforce certain preconceptions of RDF, as Dave's comment shows. Mark, didn't mean to be patronising, but I'm surprised at your statement - it doesn't make sense to compare RDF and XML vocabularies in this way. Every XML vocabulary is effectively created from scratch. Every RDF vocabulary shares the same basic information model, and they are thus already mapped at a useful level. You are right that is possible to create vocabularies in a way that minimises interoperability. The argument that it is possible to do things badly can be applied to anything. The baseline for communication is much higher with RDF than plain XML. Your URI for Zen might be different than mine, but there might well be properties in common to our data through which a mapping may be automatically discovered. It's much easier to make mappings within a well-defined architecture than it is with anything-goes syntax.

As I understand it, as long as someone, somewhere (and the world does not lack for obsessive-compulsive annotators) makes the assertion that both URIs refer to the same concept, then an RDF crawling engine can apply the mapping to the otherwise isolated vocabularies.

Such a (currently hypothetical, I believe) inferring RDF crawler can be a centralized resource or a desktop client application (or both). This raises problems that as far as I'm aware, no-one has addressed yet such as potential spam mappings, or deliberately corrupt ones, but aside from trust related issues, it's not difficult to imagine a Google-like RDF crawler that can answer the question: "what other URIs refer to this concept?", or even (though this might make some people cringe) "what are the highest relevance URIs for the string 'Zen'?" (perhaps first consulting a dictionary-like resource), and proceed from there.

Dare,
It appears that my assumption that standards bodies add order to spec development was ignorant or at least based on a faulty perception. I certainly defer to the better knowledge of those who have had experience in such arenas. Perhaps (it is my sincerest hope) Tim's draft will address the order and continuity I've been craving. The point I was trying to articulate was merely that sometimes I feel like the guy in the VW commercial who's sitting in the car waiting for the engineers to roll it off the assembly line. Apologies for honking the horn. :) Lastly, thanks to Sam, Don, Tim, Dave, Dare and those I left out not only for what you have done and continue to do, but especially for involving the community, something which I think we all value.

Dare, you're assuming that the progress on RSS has been moving steadily forward within the community, without disagreement, confusion, and a great deal of hostility. Or new XML vocabularies being defined for the same interoperability specification, which is a lose/lose -- is this a wrong assessment on my part?

And Sam, sorry if you think this is fanning the flames per your earlier email to me, but I see a great deal of hostility in other communications here, and unless you're restricting me, and it looks like Danny in what we can say, I have to speak honestly. This isn't an attempt to start a fight -- but I'm not backing down, unless you really would prefer me not to comment here. And I would respect that, and not.

As for the pushback I saw against Danny -- I realize that you all are focusing on non-RDF RSS, but when you say 'RSS', this does open the door to interpretation of the type of RSS. I did not see condescension in either of Danny's communications, and Danny and I don't agree on RDF/RSS, so I'm favoring the 'RDF side' here.

In fact, Sam, the hostility on yours and Mark's part was towards Danny was, well, surprising. Especially after I was taken to task for a much milder and more indirect statement.

I'm beginning to see a pattern here, which is unfortunate, and ultimately why we need a standards organizations -- those who control the communication threads currently control the specification, and they're not always the people who don't have an axe to grind, or even the best authority.

I want to point out one thing, RSS started as a proprietary spec. I was there. I tried to get in the door to have a say in how it was going to evolve. I was told by the Netscape people on my first try that they were tired of trying to work with the W3C, and just wanted to make some software using an open format. I could hear the wearyness in the voices. I understood.

Further, every rev of the spec has been hatched off-list without participation of any standards groups, even the much-haled RSS 1.0, they never asked anyone other than themselves if we wanted it, and when it popped up, I made it very clear that I didn't. That didn't make one bit of difference to them, they went ahead anyway. Nice and proprietary.

Yet through all this it's still the best thing going in syndication and aggregation.

As thinkers, we sometimes take a challenge to our ideas as a personal attack on us. This being a community of intellectuals, however, we all should make the effort to realize that disagreement can be healthy as long as we don't make a practice of hurling accusations, innuendos, or sarcastic remarks. Personally, I find it stimulating and refreshing to be able to interact, even in a limited way, with so many intelligent people. Thank you all for allowing me this privilege. I am certainly learning from it. Hopefully, we won't see any more of these exchanges and can continue to devote ourselves to the search for knowledge.

Sam, you're editing comments? I didn't think I said anything hostile, other than I did ask clarification from Mark -- but such is life.

Your weblog, your comments. And, I must follow earlier statement and not leave comments here again. Should have refrained, but I think the pushback at Danny just bothered me a great deal. Not that Danny couldn't defend himself, but it didn't seem right -- I'm tasked for my words, when Danny is jumped on far worse. It is the worst of weblogging, which I will cover in my Corante guest blog I guess. (Ooo, a plug.)

Bottom line, Sam: My words are not yours to edit Sam. That was very wrong of you. You would have done better just to delete the comment.

Shelley,
When I think of RSS I only consider Dave's family of specs. Although RSS Bandit fully supports RSS 1.0 as a syndication format (not as Semantic Web gobbly-gook) this is merely a checkbox item. From where I sit RSS highlights all that is exciting about using XML to build flexible, loosely coupled applications for large scale networks.

It is also the epitome of community development with all the ego, flames, and compromises that are contained therein. However in general, it has moved in a forward direction. Most of the time I disagree with Dave Winer but I'll admit that he has done a good job stewarding RSS and making it the Internet phenomenon that it is today.

When I first stared working with XML, so few years ago I thought to myself "Y'know you could build some really cool shit with this technology", it turns out that RSS is exactly the kind of technology I had in mind.

Dave Winer: "BTW, every XML vocabulary is not created from scratch. They all are based on the XML 1.0 spec. That's not chopped liver." True, but that's kind of like saying English, Spanish, French and German words are all written using the fundamental alphabet. It's true, but it's not particularly helpful when trying to translate one language to another. XML provides common syntax, not common meaning...

In any case, threads like this are fun to watch. Lots of really smart people squabling like teenagers. Too funny.

Dare,
"It is also the epitome of community development with all the ego, flames, and compromises that are contained therein."

This is certainly true of Internet culture, but it doesn't mean we have to perpetuate it. Flaming gets old. It does nothing to foster the sharing of ideas, in fact it does quite the opposite. Also, in practice while you have disagreed with me in the past, you've always been respectful even saying that my "heart was in the right place". I am grateful for that and there's no reason we all can't be courteous to one another.

Editing others comments

Yesterday's jury duty was very dull. I was almost called in once, but a settlement was reached at the last minute. However, when they sent us home last night, they said we didn't have to be in today. This is lucky because I've been out of sorts the...
[more]

Dave, I thought Dare's comment that only one or two feed readers were broken last time this was tried was a pretty direct response to your proposal. But if you're after a committment to action, I'm willing to participate in your proposed tests of the simpler approach to the extent that I am able. I would just prefer it be part of a coordinated effort with a methodology and consensus that it is a good idea first.

Sam, I apologise if you felt I was leading the thread astray, and of course the bottom line is it's your blog.

When decisions are made for good reasons, well that's fair enough, I may wave RDF's flag but happily accept that I'll probably be ignored. I can't help feeling that the plain XML RSS path is like driving down a dirt track, when there's a perfectly good highway right at the side. Whatever. But when disinformation creeps into the decision-making process, that is another matter entirely. Equating XML and RDF vocabularies leads (via ignorance) to disinformation.

re. this spec, I'd favour inclusion of the namespace on general principle, but it will also make it a lot easier to support this dialect in my tools.

Okay, cool, it seems everyone who responded said that the the AKAFR test program is a good idea. So next we need a "few sample files that have an xmlns attribute at the head of an otherwise validated RSS feed."

The thing about comparing 100 XML vocab versus 100 RDF vocabs, is that RDF was designed to allow such independently developed vocabularies to be mixed, without prior coordination.

As pointed out above, this won't automagically map everything, but it does create an environment where you can draw upon complementary vocabularies in a more fluid way, since the vocab creators don't get to dictate/predict the exact XML structures that their terms will be deployed in. This is good for decentralisation and unexpected re-use.

No hitting

Status update: I've adjusted the html tags I use to annotate weblog comments. Instead of merely a &lt;del&gt; tag, I now use a hypertext link: one with a title of flamebait, and a link to a page where further information and discussion...
[more]

Sam, no, I'm a real hardass about this for a lot of good reasons. I explained what I want to do in the proposal. What's the problem with just adding a note to the 2.0 spec if it works. Right now we don't even know if it does. This version number stuff is putting the cart before the horse.

This is why I was proposing the idea of making the namespace optional,
and stating that it is there for when RSS is embedded. That way,
RSS 2.0 feeds "in-the-wild" can stay unchanged, but when you try to
put them in a SOAP or RDF envelope you have a namespace to
attach to the elements. In my mind this causes less breakage because
when you embed RSS you are putting the RSS document in a different
context. Now some people will put the namespace in for RSS feeds
that aren't embedded and that's where Dave's AKAFR testing comes in.

Dave,
I believe we are saying the same thing, and also treading lightly. The reason I am doing so is because in your proposal you state:

"If all pass the test at some point, I would be willing to add a note to the RSS 2.0 spec, explaining that we tried this experiment and it worked."

Can we put a finer point on that? I think some RFC like verbiage that says either "RSS 2.0 feeds SHOULD contain the namespace", or "RSS 2.0 feeds MAY contain the namespace" would help clarify the intent of the inclusion of a namespace.

Something along the lines of: "The following namespace MAY be added to RSS 2.0 documents (http://backend.userland.com/rss2), see this example file. In the case where an RSS 2.0 document is embedded in another XML document, the namespace SHOULD be used. See this example."

You've proposed adding a clarification to the 2.0 specification to the effect that a namespace to be determined is OK in an RSS feed. This seems like an excellent idea to me. The roadmapyou pointed me to indicated that version numbers 2.0.x will be used for such clarifications. This makes sense to me.

I gather that you would prefer not to see the version number in either the version string or in the namespaceURI. I'm OK with either of these notions, but instead of my guessing (something I have done twice now, both times incorrectly), let me know what you would find as acceptable.

Once this is settled, I'll create a template and people can use my various feeds as one of the ones that they test against.

This offer is not only open to Dave Winer. I have a history of supporting multiple specifications independent of the source.

I'm generally neutral on the version number debate. I think a change in version number would help clarify that a change like the addition of a namespace even if made optional. Then again RSS 2.0 started out with a namespace. I think Dave's point that "right now we don't even know if [adding a namespace works]" is fair enough and we should return to this discussion once that has been confirmed.

I'm fairly optimistic that it will work in the majority of cases. I realized after I made my last post of the night that since October my RSS 2.0 feeds declare a default namespace and an "unusual" one at that. (By no coincidence they comply to the RSS profiles I've proposed. Nothing like eating your own dog food.) I have not once ever received a complaint or indication that someone could not consume my feed with their aggregator or other RSS-enabled tool. I get ten's of thousands of hits each month on my feeds and the referrers indicate all the major aggregators and then some are being used -- Radio, NetNewswire, AmphetaDesk still appear in my referrers. I used to see other such as RSS Bandit until some aggregators stopped abusing the HTTP referrer header.

This is not to say we should test adding a namespace to RSS 2.0 feeds. I know I don't get the flow that some others in this discussion get. I'm just pointing out the reason for my optimism that they will be an overall success.

Joe, actually I think it's best to describe the experiment that was done, and to report that none of the aggregators broke, and explain why that would be useful in what cases, and never mind the MAY or SHOULD. And of course please understand this is off the top of my head, and I want to give it some more thought.

Also a heads up, I am about to hit the road again, for parts unknown. I have to be in Boston on Monday and will probably be back online before then, but it's not a sure thing.

MAY/SHOULD/MUST is pretty standard language for specifications; anyone reading the RSS specification with the intent to implement it would know what they mean. Describing the experiment is also a good idea to give historical context, but then give the final word: "An RSS 2.0 feed MAY include the following default namespace..." to give consumer authors a heads-up to handle this contingency.

BTW, I added the default namespace http://backend.userland.com/rss to my main RSS feed. Let's see what breaks. (My RSS parser already supports this namespace, and has since the early days of the RSS 2.0 draft. If we're going to be using a different namespace, let me know and I'll make the appropriate modifications.)

Thu 05 Jun 2003

Who owns blog comments?

Who owns blog comments? Many of the longtime tech bloggers were arguing about RSS this week, but something new happened: the blog owner struck out comments that he found over-the-top. As usual on any meta-breakout in a discussion, more discussion......
[more]

Letting the dough rise

I haven’t had much time to work on Hep lately. I’ve been wrapping up a 9-month project at my day job, which has been taking up most of the time I would usually have for Hep and other fun things. But I think the break has actually been a...

Sat 07 Jun 2003

Pub or party online?

[W]e wind up with two different approaches to community. Shelley's implies that the comments section of a weblog is akin to a pub, where any member of the public can come in and say whatever they want. Sam's would instead liken it to a private party...
[more]

Sun 08 Jun 2003

Sam Ruby's moderation policy strikes out

Sam Ruby undoubtedly means well, but in trying to encourage civility on his weblog, he has implemented a bizarre moderation policy. If Ruby doesn't think you're playing well with others, he'll mark up part of your comment with strikethrough text or ...

is an unacceptable restriction, and is completely inappropriate in a spec. A spec defines a format. It may even give examples of intended uses. It does not tell me how I may or may not innovate with that format.

RSS has been used for lots of things that it wasn't originally intended for -- weblog import/export, for example. Placing restrictions on innovation up front just dooms you to failure.

Randy,
I simply don't see the point of writing a spec simply to say "if you want to include the elements from RSS in the content of another XML format please pick some random namespace name for them instead of leaving them as unqualified names"

Mark, I know what you mean. I think I'm trying to be too political, but I don't want to propose RSS 4.0, I'll get killed. That restriction was another way to satisfy Winer's REQ of minus namespaces, that it not be used in place of RSS.

Dare,
You are correct that schema-less and namespaces-less use of XML has a lot of value. For example, RSS is the #1 XML Web service. But, wouldn't you agree that RSS needs to come together with XML schemas and namespaces for it to succeed in enterprise class applications? Use of random XML elements that are not backed by a schema is a sure way to confuse anybody trying to read your code. This is where RSS 1.0 has a foot up on RSS 2.0.

I'll leave it to be consumed by anyone who thinks it worthy. If you don't think it's worthy, then you may opt-out of consuming it :)

Thu 01 Apr 2004

RFC: PaSSAPI

Here's the WSDL, C# and an abstract implementation w/ documentation for PaSSAPI. This is a Request For Comments in order to first introduce and receive feedback for making this a great API. Where did PaSSAPI come from?PaSSAPI started as an idea of...

Mon 06 Sep 2004

Sam Ruby: PSS

Thu 12 Apr 2007

Bloggers on patrol

The web today is a-flutter with calls for new “standards” to fight back against the increasing problem of hostility in the world of blogging. This comes on the back of a spate of unpleasant, unprovoked attacks on various bloggers...

Sun 10 Aug 2008

PSS and FeedState

Please excuse the emptiness of this blog, as I’ve been on vacation for the last month. Now that I’m back, I’m getting ready for a great autumn for RSS. Once I get back in the saddle, I’ve got two things I want done. I intend on getting PSS...

Mon 18 Aug 2008

Randy Charles Morin Becomes RSS Advisory Board Chair

When I became chairman of the RSS Advisory Board two years ago, one of my goals was to resist the temptation to bogart the job. I wanted to find somebody who could keep the group going as chairman and bring a fresh perspective to the tasks of...