It’s just data

Jon's conversation with Mr Safe

Jon Udell: I'm never a fan of fixing what ain't broken. Arguably, though, there was no other way forward in this case. The worm at the core of the weblog apple had to be extracted. It's true that vast numbers of yet-to-be-written RSS applications need no more than what RSS already does, or can be extended to do using the mechanisms it sanctions. It's also true that vast numbers of yet-to-be-written RSS applications will require RSS to evolve. It had to become possible for that evolution to occur in an open and vendor-neutral way, and when the dust settles I think it will be possible.

Dare Obasanjo

Sam,
I've posted my thoughts on this at http://www.kuro5hin.org/story/2003/6/27/123142/302 and I exchanged mail with Jon yesterday. If Echo is simply going to be RSS++ then I see no reason to do it. The only reason I see it as being compelling is that it will unify a number of competing yet overlapping technologies so folk me who are building blog related tools don't have to implement several half-assed technologies but instead just one or two good ones.

I understand why people seem to think that this is all about RSS. Like Jon said, RSS is fairly trivial to implement and is a good enough technology. All the innovation in RSS happens outside the core spec anyway which I assume is why the "funky" business started in the first place. I doubt that the Echo syndication spec will be any difference. The payoff won't be in better specified equivalents to pubDate and guid after all they work fine enough today.

Message from Dare Obasanjo at

Sam,
Why doesn't your implementation of the CommentAPI correctly handle " ?

Posted by Dare Obasanjo at

The funky business came about because Blogger was switching its RSS from 0.91 to RDF, and we had an understanding I thought, that we wouldn't do stuff like that to each others' creations. I didn't call the MetaWeblog API the Blogger API, for example. When I implemented Trackback I used the RDF format they liked, because that's what it meant to be compatible. So for UserLand's competitors, as I have explained ad nauseum, it's just not fair for them to do it differently. They wouldn't like it, I'm absolutely sure of it, if UserLand did to them what they did to UserLand. This has still not be resolved, the issue has only been obscured in the mad rush to Echo (btw after re-reading Tim's essay I see where the name comes from, and shame on you guys, you should really grow up already, it's unbecoming of an industry to behave in such a shameful way). At the same time as Blogger was changing, Movable Type was already shipping with RDF as their default.

I wanted to say that I appreciated not-funky RSS support, and tried to call out positive examples of it where I could. There's a lot of it out there, in fact, outside the software industry, among content companies, with very few exceptions it's all 0.91 or 2.0 (and lots of 2.0 these days).

Some people, for whatever reason, want to keep there from being a consensus. In the Blogger case, I have no idea why they did it, I think I've always been kind to them, helping when I can to create formats and protocols to make the products work better together. To switch from 0.91 to RDF seemed like a totally unnecessary slap in the face. When I asked why they did it, I got no answer (as usual, they rarely respond to questions).

So I responded in public, characterizing what they did as funky. You may not have figured it out, but the message was for them. Their answer was to rip up the pavement. Same with the Movable Type people. Pretty damned disappointing. Nice logo though. Maybe someone could do a nice logo like that for RSS? It would be much appreciated.

Maybe Ben and Mena could be kind to RSS 2.0 and make it their default for TypePad, I'd be happy to do a quid pro quo. I just want this format to be solid and well-supported, as I explained in my endorsement of Echo.

End of ramble. Have a great Saturday.

Posted by Dave Winer at

Jon Udell's "hit the reset switch" analogy is a good one, but I'm not sure if I see it in the same light he does.  Think of when one has to hit the reset switch on a Windows box ... either some broken driver code, or version incompatibilities among DLLs, or whatever has put the system in an incomprehensible state and the only thing to do is start overthing over.  It's an annoyance and an inconvenience, but a couple of minutes later you have a reasonable stable system once again.

That's how I see Echo ... not "tearing up the pavement".

I also like Udell's mention of the "vast numbers of yet-to-be-written RSS applications."  That's the real purpose in doing this.  Maybe RSS [pick your flavor] is solid enough for the early adopters who will call each other or blog about their implementation problems and get quick answers.  That's NOT going to work for the Mr. Safes, or more particularly the geeks working for him. They'll look for answers in a real spec, and if they don't find them they'll say "Mr. Safe sir, I know you had a nice chat with that InfoWorld guy and came away convinced, but this stuff is NOT ready for prime time. We can implement what WE think [pick your favorite RSS spec] means by various things, but we can't guarantee that others will interpret them in the same way ... and there's no way to decide who's right."

The trick is to make some RSS-like syndication, posting, etc. format and interfaces ready for industrial strength implementation and interoperability testing.  That's HARD SLOW WORK, as Tim Bray keeps pointing out, but it's got to be done before those "vast numbers of yet-to-be-written [RSS-ish] applications" can come online.

Posted by Mike Champion at

Mike, what's wrong with the BBC feeds?

http://backend.userland.com/2003/06/24#a302

Just interested in your opinion applied to a real-world example.

Ever wonder how much time there was between the first suggestion that the BBC might offer syndicated feeds and the release of all the feeds?

Do you think there's one or more Mr Safe's in that organization?

Posted by Dave Winer at

I have no idea about the situation at BBC.  Did they refer to the spec to clarify how to resolve problems, look at some code, do ad-hoc testing with various aggregators, or what?  I suspect more of the latter two than the first.  How much help did they get from the RSS community?

All I know is that I've learned to NOT extrapolate the experience of committed, interested, highly competent early adopters to predict what will happen when the whole world joins. 

Look at the experience of the soapbuilders list, and the fact that it took a whole organization (WS-I) to just write a profile of SOAP 1.1 that reliably interoperates, and a 3 year effort at W3C to distill all that experience (and some "creativity" as well) into a full-fledged formal spec... That's no slur on any previous version of SOAP, just evidence that it is a long, hard process to get specs nailed down to the point where developers who aren't part of the community that developed the specs can just pick them up and write interoperable implementations.

Posted by Mike Champion at

Well Mike I don't see the BBC as an early adopter. I see what happened to SOAP as an utter disaster, to be avoided at all costs with RSS. I think you and I do XML stuff for vastly different reasons. I'm an app developer, and XML is the interchange format I use. I never pretended to understand what the BigCo's wanted from SOAP, but thankfully I can use SOAP 1.1, and if they ever succeed at deprecating that out of existence I will be happy with XML-RPC.

Posted by Dave Winer at

In my opinion the BBC and other traditional push style publishers are exactly the kind of people who probably won't be significantly better off by the Echo work. As Jon mentioned, those people could be satisfied by ancient CDF. All they typically want is "Hey, we should provide potential readers with recent headlines, their date of posting and a link to get back to our website".

Of course, later on they may realize that they want to place rich content in there such as InfoWorld tried with ads and then they may begin to hit some of the issues that exist with the currently underspecified RSS 2.0.

To some, just the fact that Echo will probably clear up the issues with posting rich content in an RSS feed makes it worthwhile and I'm sure the folks at BBC will be happy for it the day they decide to start running ads in their feeds.

Me, I'm interested in higher up in the stack as I've mentioned earlier but the core has to make sense and it has to interoperate for it to be useful. Echo will give me both of these.

Posted by Dare Obasanjo at

Speaking about Mr. Safe, I'll play Mr. Safe for a bit:

Here we are using the OCS format for specifying groups of feeds for Jetspeed.

People in there asked me what is the most common way to specify the set of feeds a site/blog is offering? I rebroadcast the question and add another one: Is this relevant to the echo effort?

When I looked at this, I noticed I have not seen Ian Davis (the author of OCS) around here or the Wiki. He has, though, posted this month on unified RSS, with some interesting ideas.

Posted by Santiago Gala at

What impresses me is that Dave Winer expects those he calls competitors to follow his lead. 

From where I sit, Blogger and MT combined have the superior market-share.  If they both feel that RSS/RDF is not controlled by a single vendor where RSS w/o RDF is, then it seems to me that they might see a competative reason to wrest control of RSS from their competitor by supporting the competing standard.

Funky or no, it seems to make good business sense to me to compete rather than cooperate in this instance.

Posted by Mark A. Hershberger at

Mark, competing on the basis of incompatibility is nasty esp when you think about it from the users' point of view. What do they gain from it?

At least Blogger and MT ought to have the decency to change the name of the format, because RSS doesn't compete with them, even if UserLand does.

BTW, your argument is kind of weird, you say the other two companies have more market share than UserLand, so if that's true (probably, in certain dimensions) what is it that they're so worried about?

And as I've said elsewhere, I don't control RSS, neither does UserLand. I couldn't change what it is. If I tried it would go on being what it is.

Regardless, I hope they're not doing what you say they are, it would be unprincipled, without honor.

Posted by Dave Winer at

Please forgive me for my ignorance of the history of RSS -- I am a new Google engineer who recently started working on Blogger.

The reason why Blogger started generating RDF is purely technical.  Blogger users can specify "related URL" as one of the properties of an entry.  This URL is distinct from from a permalink URL, and it usually points to a different site.  We couldn't figure out how to represent this URL within the constraints of RSS 2.0 spec.

I don't have enough information to form opinions on issues surrounding RSS name.  One way to address these issued is to choose a brand new name -- something Pie is doing.

Personally, I think that RSS 2.0 is more elegant than RDF-based syndication.  I would like to see it used as a base for the new format -- in some ways it already is, since experience with RSS 2.0 sets the stage for the discussion.  Unfortunately, RSS 2.0 Roadmap limits the available options.

Posted by Misha Dynin at

the other two companies have more market
share than UserLand, so if that's true
(probably, in certain dimensions) what is it
that they're so worried about?

Misha provided your answer, I think.  RSS 2.0 provides them no room to grow when they want to add funk(y)tionality.  Despite the claims that you don't control RSS, you've put out a lot of stop energy whenever people try to do more with it.

If I were a UserLand competitor and UL's major shareholder did this, I would find a standard to work with where he couldn't affect me.

Posted by Mark A. Hershberger at

Misha, what you describe is what the item-level <link> element is for. I wrote up an answer to another developer's question in this area a few days ago. In other words it would be great if you guys used RSS 2.0, and no reason why you shouldn't. Glad we got that out in the open and solved!

Posted by Dave Winer at

Dave, do you not get that the very fact that you have to explain that is one of the biggest problems with RSS 2.0?  The RSS 2.0 spec is very under-specified, IMHO.

I'd like nothing better than to see the industry remain with / converge on RSS 2.0 - but some things have to be done.  No more FUD.  A solid profile.  And some flexibility from you.

Posted by Greg Reinacker at

Greg, as it says in the spec itself, RSS is an imperfect format, but I'll tell you what -- every format that's used in the real world is imperfect, and so is every spec. We live with it, like our friends and lovers are imperfect too. Maybe that's not so important as how they are good to us and make things possible that otherwise would not be possible. Anyway, have a great Saturday and onward ho.

Posted by Dave Winer at

Mark, I put out lots of stop energy when people try to break RSS.

In any case, RSS 2.0 totally provides for what Blogger wants to do. If they had asked me when they made the decision I would have told them the history and provided the help they need, happily.

Take care.

Posted by Dave Winer at

Dave, thank you for the clarification.  Unfortunately the timing is suboptimal -- it would be confusing to Blogger users if we switch the feed to RSS 2.0 now, only to switch it to Pie/Echo format a month later.

Personally, I'd like to see you contributing more of your technical expertize to this new effort, within the guidelines that Sam established.  I wonder if relationship between RSS 2.0 and Echo can be explicitly acknowledged by all parties, irrespective of backwards compatibility and naming -- Echo becomes "next version of RSS 2.0", and RSS 2.0 is credited as "the foundation of Echo".

This is my first experience with standardization process, so please forgive me if I am a bit naive.  But I look at it as a great opportunity to improve the new medium -- instead of focusing on past misunderstandings, let's discuss new features, such as making the comment/trackback protocol spam-resistant with HashCash.

Posted by Misha Dynin at

Misha, that is really unfortunate!

What about all the Blogger users who have RSS 0.91 feeds?

Don't you care about them?

Amazing. Breath-taking.

Posted by Dave Winer at

What about all the Blogger users who have RSS 0.91 feeds?

Blogger still generates 0.91 feeds for some users.

And it is really unfortunate that this thread has to end like this.

Have a great weekend.

Posted by Misha Dynin at

Misha, how do you support those users when they ask where you're going to take them in the future and why? I agree it's unfortunate. A little communication would go a long way. For example, this morning I decided to look at the MetaWeblog API to see how easy or hard it would be to add an appkey. It wouldn't be hard. In fact the new entry-points have an appkey, believe it or not.

You know, a lot can be accomplished just by communicating. You're the first Blogger guy who has responded to my questions in a long time Misha. When I asked Evan for comments about the MetaWeblog API, several times, he never responded. Can you fault the MetaWeblog API for that? No way.

It wasn't that long ago that Sam Ruby was blasting the API as inadequate here, for something that was clearly covered in the spec. That made me think then and think now that he was and is more interested in replacing it with his own work, than in truly having tools that work and users that get new features.

You said there was a problem with RSS 2.0, I showed you how to solve it, the way many others have, and you still don't want to support RSS 2.0, you still want to change it. Now I have to wonder why. Why?

Posted by Dave Winer at

How easy or hard would it be to add unicode support to the MetaWeblog API? Easy, I'd imagine, because it's just a virtual restriction in XML-RPC... right?

Posted by Marcus at

Sorry I missed it, but where did Misha say anything about changing RSS?

Also the reasoning behind not using RSS 2.0 at this point in time sounds perfectly valid to me - consider the end users.

I certainly don't think it's fair to accuse Sam of being interested in replacing the API with his own work. There's absolutely nothing to suggest this on the project Wiki, which is where the development process is focussed. But I really hope he will contribute a lot in this area in future, I think his (and Joe's) work on RESTLog and SOAP versions are a good start.

Posted by Danny at

Marcus - I think you're right (on your blog) to highlight the i18n problem with XML-RPC as the main reason the existing APIs need replacing.

But if you drop XML-RPC, then I think it's worth reconsidering the requirements again from scratch (as I think Joe did with RESTLog?). Also, whatever the implementation of the API it needs to play well with the serialization format. Again, I reckon best start from scratch to avoid any clutter from the legacy syntaxes/APIs.

Posted by Danny at

Dave - careful with words like blasting.  I asked a question.  Perhaps a dumb question, but it happens.

Listen to what is going on.  A conversation.  You are participating.  Blogger is participating.  A large number of people are listening.

This wasn't happening a month ago.

If we can find a way to achieve the four goals listed at the top of the roadmap with existing formats and protocols, we all win.

Lets see if we can keep to a high level of respect in discourse.

Posted by Sam Ruby at

I'll say this once here, it's been said on the XML-RPC mail list, and always results in a flame war, and I'm just not up for yet another one. Marcus that's not your fault but it's a fact, some people just want trouble, not answers.

Here's the scoop.

1. XML-RPC is XML. (See the spec, it's very clear about this.)

2. Read the XML spec to see if it allows unicode.

That's all I have to say on that.

Posted by Dave Winer at

"Easy, I'd imagine, because it's just a virtual restriction in XML-RPC..."

Note the question towards the end of the XML-RPC spec: "What characters are allowed in strings?", and the answer to that question: "Any characters are allowed in a string except &lt; and &amp;, which are encoded as &amp;lt; and &amp;amp;."

I asked that question, and unlike most other people, I also know the context: it's a direct reference to the "ASCII string" item in the "scalar" list: did that really refer to the 7-bit US-ASCII standard (ISO 646), or was it just a sloppy way (but oh so common, outside nitpicking geekland) for an American to say "text string".

Given the context, the answer was clear: XML-RPC is XML, and you can use any character XML allows you to use. 

Unfortunately, Dave added the comments towards the end, instead of reworking the relevant parts of the specification.  But that's history; just use a little common sense, instead of "reading the specification as the devil reads the bible", as the swedish expression goes, and you'll find that most XML-RPC toolkits just works...

Posted by Fredrik Lundh at

This is a perfect example of what I was worried would happen. :(...... [more]

Trackback from Andrew Grumet's Weblog

at

Dave, interesting timing ;-)

I've said this before, and I'm saying it again: maybe it's time to add a note to the XML-RPC specification, reflecting best practices.

Or just remove "ASCII"; it's a typo anyway.

Posted by Fredrik Lundh at

Fredrik it is a typo. And if you would agree to be my flame shield, maybe my doctors would permit me to do it. ;->

My experience has been that the people who have this problem are lawyers more than programmers, people who want a fight instead of software.

Sam, sorry for using the word "blast" -- I am not a lawyer and this is not spec text, and once submitted I can't edit it, so we always have to cut that kind of slack. I'm esp in the hot seat here, I hope you get that, and cut me an extra length of slack. You wouldn't believe the personal shit people give me. Anyway, onward.

Posted by Dave Winer at

Sure, Dave.  Feel free to remove it, and replace it with a footnote, asking people to contact me if they have a problem.  I'm pretty good at dealing with (sea) lawyers...

Cheers /F

Posted by Fredrik Lundh at

Summary here:

http://www.effbot.org/zone/xmlrpc-ascii.htm

Posted by Fredrik Lundh at

I'll B.O.G.U. for Blogger

One of the many things the Echo folk want to reinvent is the MetaWeblog API. Of course this makes my teeth grind, because I know how much time and energy went into making it work, not just for UserLand's tools, but for many others. The only major...

Excerpt from Scripting News at

Rather than change the xml-rpc spec bit-by-bit as all the errata trickles back in, how about setting up an errata page to collect them, in preparation for a "2nd edition" of sorts.  Link to the errata page prominently from the xml-rpc homepage, right next to the link to the spec.

I would be more than pleased if Fredrik would like to take lead in this matter.

Posted by Ken MacLeod at

If we can find a way to achieve the four goals listed at the top of the roadmap with existing formats and protocols, we all win.

How about adding pages to the wiki called JustUseRSS2.0 and JustUseMetaWeblogAPI linked from the roadmap and let people hash out the suitability there?

We'd still need to settle the well-formed entry discussion, and the archiving discussion to reach full interoperability.

Posted by xian at

"how about setting up an errata page"

Good idea, as long as I can keep it on a rather informal level (and host it on my site, at least as long as it's evolving):

  http://effbot.org/zone/xmlrpc-errata.htm

On the other hand, I'm "not part of the weblogging community", according to a nastygram I just received, so the question is that anyone involved with "Echo" will care.

(the XML-RPC community already knows all there is to know, but we're obviously talking about an entirely different group (or kind?) of people here.)

Posted by Fredrik Lundh at

Dave, Fredrik, it is simply not true that XML-RPC's lack of support for Unicode was a "typo".  The record is very clear on this.

http://www.google.com/search?q=dave+winer+xml-rpc+unicode

Furthermore, simply changing the spec at this point to support Unicode in XML-RPC strings would result in silent corruption of data in many cases, cf. http://www.megacz.com/xmc/faq.html

XML-RPC is what it is: a XML-based protocol that restricts strings to 7-bit ASCII, a restriction that is upheld by several major implementations and which can not be changed without serious breakage.  And we all know that this sort of breakage is unacceptable (since it would create a discontinuity).  Support for ASCII-only XML-RPC clients and servers must be maintained for all time, which makes XML-RPC unsuitable for any new work that cares about internationalization.

The only logical choice is to base new APIs on something other than XML-RPC.

Posted by Mark at

Fredrik, XML-RPC strings are 7-bit ASCII.  Your claim that XML-RPC "supports" Unicode because Dave said so in a mailing list is just ridiculous.  Frontier didn't (doesn't?) support Unicode properly in XML-RPC strings, and it was the first major implementation.  God knows how many other implementations since then have needlessly restricted/munged string data based on this restriction in the spec (and years of subsequent refusals on Dave's part to deal with the issue properly and rev the spec).

XML-RPC strings are 7-bit ASCII.  Anyone who implements it differently is breaking the spec.  The fact that "most" implementors have ignored this limitation and supported Unicode anyway is simply beside the point.  Interoperability is not based on individual implementors second-guessing the spec.

Posted by Mark at

Some people just don't want to take yes for an answer. Mark -- give it up already. What a sore winner.

Posted by Dave Winer at

Mark, I was there in the beginning, you weren't.  You're just a fake.

Posted by Fredrik Lundh at

I was there from the beginning as well.  For the benefit of forward progress, "no comment."

Posted by Ken MacLeod at

Let the record reflect that we have clearly communicated a solid technical reason why we can not use XML-RPC for this project, and both Dave and Fredrik have responded with nothing more than personal ad hominem attacks.

Years later, when Dave and/or Fredrik lament (to a new audience that does not know this history) that this project should have used XML-RPC, "if only people had chosen to communicate instead of engaging in personal attacks", let us point the naive members of that new audience to this thread.

Posted by Mark at

Mark, I'm sorry I don't know what else to say to you. Is there any way for me to win with you? Could I do anything that you would approve of? Yours in utter exhaustion, Uncle!

Posted by Dave Winer at

BTW, to Mark, go look deeper in the archive of the XML-RPC mail list. You will find a message where I said clearly that XML-RPC is XML. It's only lawyers who like to fight about this. Implementors, as Fredrik says, got the info they needed a long long time ago. If you didn't get the message through the grapevine, how could you mistake what I put here in Sam's weblog and on Scrpting News today. This is what I meant about being a sore winner. You got what you wanted presumably, and you're still raging mad. Why? I don't get it.

As to why I didn't change the spec, l;ook at what Ken says for the answer. He wants me to re-open the whole thing. No way I'm signing up for that. It's way way late for that. The damn thing is deployed. Maybe you need to reinvent it. If so, I highly recommend you use SOAP, that's what it is, a buzzword compliant reimplementation of XML-RPC.

Posted by Dave Winer at

(Ah, the "royal we", again. The "exclusive community", with initiation rites and selected readings, complete with scornful annotations. "Show us your winer number, and you can play."  Sounds like a nice little sect...)

But back to XML-RPC: anyone with a googlebar can of course dig up any number of quotes that matches their own opinion.  All I've been saying is that I asked Dave about this early on, and he told me that there was no US ASCII limitation.  XML-RPC is XML, and all characters are allowed.

Strangely enough, that doesn't stop you from knowing, for sure, that it isn't this way (despite the fact that relevant parts of that discussion was added to the specification in 1999). 

Maybe you could answer two simple questions:

- Were you there at the time?

- Do you know exactly what discussions I had with Dave, and with others, when I implemented xmlrpclib?

Posted by Fredrik Lundh at

I think what is sad as a end user we see you all just fighting and it will not be long before it starts to have a negative effect. Most end-users do not understand RSS, XML, RDF, ECHO etc.
If you all could quit fighting for your little piece of the turf as this is very obvious turning into a turf war. The sporadic flaming proves to me that some of you are very immature and not true professionals.

The hand writing is on the wall on what the objectives of some parties are and it leaves a bad taste in my mouth.

You all need to be locked up in a room for a week to hash this stuff out. Just don't forget the end users out here like me.

Posted by Geek at

Just taken from the XML-RPC specification post at http://www.xmlrpc.com/spec:

If international character support is indeed acceptable and supported since 1999, then why has the spec been so poorly maintained that is does not reflect this fact? This is clearly misinformation and an aggregious disservice for those who trying to follow the great work you did.

Posted by Timothy Appnel at

The quote from my last comment got eaten by the comments system.

Tag: <string>
Type: ASCII string
Example: hello world

Posted by Timothy Appnel at

Dare Obasanjo

Mark and Dave,
  Is this a discussion about whether the blog posting API that Echo specifies should use XML-RPC ? If so, isn't this jumping the gun given that the discussion of the blog posting API hasn't even begun?

If it isn't then what the heck is it about?

Message from Dare Obasanjo at

Dare, it's in the vein of "can we use the existing specs to accomplish what we need to do, and if not, why".  In this specific case, the topic is "if we need to be cleanly and thoroughly specified, can we use normative references to specs that are not", and then "what can we do to make the existing specs cleanly and thoroughly specified."

So, no, it's not specifically in reference to nee Echo using XML-RPC, but in moving forward with blogger/metaweblog API, which are XML-RPC based.

Posted by Ken MacLeod at

Dare Obasanjo

Ken,
Thanks for the clarification. If there was one thing that has to be redesigned with generic publishing and editing of content in a secure manner in mind it is the ghetto Blogger/MetaWeblog APIs (no offence intended).

Keeping the syndication format as RSS and just tightening the spec + deprecating the stuff that no one uses was actually a viable option in the area of syndication although restarting with the Echo project was the quickest and least frustrating way to get around the Stop Energy. However I definitely don't think this is the case with regards to the blog posting/editing APIs.

For one they probably are better of described in a RESTian/protocol independent manner so that functionality such as security can be layered upon instead (e.g HTTP authentication for the RESTian approach or WS-Security for the SOAP approach) instead of this nonsense of passing around passwords in plain-text. I'm sure the mythical &quot;Mr. Safe&quot; would just love to use a technology whose idea of security was nonexistent.

Message from Dare Obasanjo at

"For one they probably are better of described in a RESTian/protocol independent manner so that functionality such as security can be layered upon instead"

Hey, you're cheating: that's a valid reason for not using XML-RPC ;-)

(many XML-RPC implementations do support HTTPS/SSL, but far from all).

The "ASCII" argument is a red herring, though.  But I think most people understand that by now.

Posted by Fredrik Lundh at

Well you all have went and done it now if you haven't looked at Dave's site you ought to. Sometimes I think the weblog community ought to get together and beat some of you guys down. You need to wake up act responsible and play in the sandbox.

I have seen this happen too many times in other communities work together play nice and be gentleman.

Posted by Geek at

"why has the spec been so poorly maintained that is does not reflect this fact"

It does reflect it, if you look at the entire specification (including the Q&A section), and not just the section you quoted.

As for why Dave hasn't change the text,
my guess is that everytime he's mentioned the possibility, some enthusiast has piped up and said "but hey, why not fix all the nits while we're at it", at which point Dave goes "Oh no, here we go again" and tunes out.

(But that's just my guess; your guess is probably as good as mine).

And really, it's not that important: if you're publishing an XML-RPC API, all you have to say is to "Note that to use international characters, you have to use a toolkit that supports non-ASCII strings.  Most toolkits do."

Posted by Fredrik Lundh at

Re: "if you look at the entire specification (including the Q&A section), and not just the section you quoted."

Thank you for clearing that up, Fredrik.  While we are in agreement that not all XML-RPC implementations support Unicode, I was under the mistaken impression that the XML-RPC spec did not claim any support for Unicode at all.  In fact, as you have correctly pointed out, the spec itself is self-contradictory, in some places claiming ASCII, in other places claiming to support anything XML supports (including, presumably, Unicode).  As you correctly point out, this is one of those things that implementors need to sort out for themselves (perhaps by asking you, an early implementor, or perhaps by asking Dave, the spec author).

Of course, the fact that the spec is self-contradictory makes the interoperability problem worse, not better.  I for one certainly do not wish to place this kind of burden on implementors of new formats and APIs.  "Just ask Fredrik if you have any problems" is not a solid foundation for interoperability.

I hereby change my objection to using XML-RPC from "the spec doesn't support Unicode and some major implementations don't either" to "the spec is self-contradictory and some major implementations don't support Unicode."

Posted by Mark at

"It does reflect it, if you look at the entire specification (including the Q&A section), and not just the section you quoted."

I have read that spec numerous times over the years and just did it again. Please quote the passage that I am missing instead of vaguely referring to it.

There is one mention of ASCII. (The one I quoted.) There is zero occurances of UTF8, UTF16, or the word "international" in the entire document. Encode or encoding only refers to &lt; and &amp; or embedding binary data.

I have asked this question many times and it has never been answered with any type of clear and explicit citation from an "official" document i.e. the specification.

I'm still waiting to be pleasantly surprised.

Posted by Timothy Appnel at

Dave, recently I had to make a decision wether to go for XML-RPC or pure XML on HTTP GET, PUT, POST, (or maybe SOAP) for a project.

I read the XML-SPEC, found the note deeply down about "any character", and then found the string as "ASCII text". My take was that, to be safe, I had to encode strings and use the base64 type. I discarded XML-RPC for this project.

I was acting as Señor Seguro, which it Mr. Safe in Spanish. I could not afford having dangling, unclear or unsound character support in our tool, or having to fight with diverging implementations of the spec in several languages. I have had enough i18n problems already.

Inconsistencies in open specifications I can read as inmatureness. But when I found and read list discussions, and found that there seemed to be agreement on the spec interpretation and errata or minor release were not options, and that the spec was not open, I felt FUD, and decided to stay away of it. This was my mental process. YMMV

Posted by Santiago Gala at

It has been my experience that an explicit mention (ASCII) carries more weight then an inferred one, but Mark's read of the XML-RPC spec is fair enough. I still cannot support it for future applications until these ambiguities are rectified.

Posted by Timothy Appnel at

Dave Winer vs. Mark Pilgrim

As we’ve mentioned before, there are some great conversations going on at Sam Ruby‘s site concerning what is currently being called Echo. But in the schoolyard that is the Internet, Dave Winer and Mark Pilgrim need to be separated in...

Excerpt from dionidium.com at

Specifications

A spec has to be specific or it's worthless. If after a spec is published it becomes a apparent that the spec isn't specific enough then a new revision of the spec must be revised to address the lack of specificity. If the spec is frozen at a... [more]

Trackback from Larry's Log

at

Goldman

Watch as the shit showers down over on Sam's blog......... [more]

Trackback from vedana.net

at

I'll B.O.G.U. for Blogger

One of the many things the Echo folk want to reinvent is the MetaWeblog API. Of course this makes my teeth grind, because I know how much time and energy went into making it work, not just for UserLand's tools, but for many others. The only major...

Excerpt from Scripting News at

I'll B.O.G.U. for Blogger

  I'll B.O.G.U. for Blogger I'll B.O.G.U. for Blogger. One of the many things the Echo folk want to reinvent is the MetaWeblog API. Of course this makes my teeth grind, because I know how much time and energy went into making it work, not just...

Excerpt from Audioblog/Mobileblogging News at

Pingback from 0xDECAFBAD

at

Please fix the XML-RPC spec

I've written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it's the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of languages...

Excerpt from 0xDECAFBAD at

Please fix the XML-RPC spec

I've written before that I love XML-RPC, and that it has served me well in the past couple of years. I think it's the right tool for a broad range of jobs. But, after having studied the spec, and after having implemented it in a handful of languages...

Excerpt from 0xDECAFBAD at

Jon's conversation with Mr Safe. Jon Udell: I'm never a fan of fixing what ain't broken. Arguably, though, there was no other way forward in this case. The worm at the core of the weblog apple had to be extracted. It's true that vast numbers of...

Excerpt from TIG's Corner at

Dave Winer vs. Mark Pilgrim

In which we get bored listening to these two fight....

Excerpt from dionidium.com at

By: rhyax

This conversation may be of interest. I mean, if you enjoy useless bickering....

Excerpt from Comments on: Scripting News is taking a break. at

Add your comment