intertwingly

I imagine it would also be possible to make a necho-to-funky-rss XSLT stylesheet that would enable use of the current generation of RSS newsreaders to read necho feeds. I don't have the expertise to do that, though.

A XSLT script to translate Necho to XML-RPC serialization will be possible, but won't help with XML-RPC API at all. The reason being that XML-RPC APIs are function libraries much like local dynamic-link libraries are. If you use XML-RPC, you never directly touch the XML source at all. XML-RPC is just remote procedure calls that happen to use XML for serialization and HTTP for transport, but the programmer calls functions and passes on data structures.

So what is needed isn't a translation of the underlying XML, as that won't help anybody, but what is needed is a standard way of translating the Necho structures to actual data structures using the simple types and compound types that XML-RPC knows of (so you can use int, float, string, datetime for simple types and list, structure for compound types).

I did something like this in http://intertwingly.net/wiki/pie/SampleXmlrpc down in the bottom in my Python example.

I voted +1 on the "do REST first, XML-RPC/SOAP can be derived from that", because the transfer from Necho structure to data structure can be made automatically. It's just not possible with XSLT ;-)

It's quite funny how many people discuss XML-RPC in the Wiki and even vote to dump it, without actually knowing what XML-RPC is and how it is used. This is especially funny since XML-RPC is definitely the standard protocol basis of today for all blogging APIs, so one would think that people know what they are talking about ;-)

Just to be correct, of course there is a situation where something like XSLT translations from Necho to XML-RPC serialization might help: if somebody who built a REST based tool want's to provide the XML-RPC API. Since he will work with XML documents, he will have to accept XML-RPC serialization POSTs, translate them to Necho, do his stuff and translate the result back to XML-RPC serialization.

But I think the mapping should be done from the API level and the XSLT to do this translation should be done based on that. Because otherwise the translation will be too "abstract" and make life of programmers unnecessary complicated.

So my former comment stands for people already in the XML-RPC using field. They won't get anything from an XSLT translation, as they never talk with the wire directly, but just pass around data structures.

Last update: 04/07/03; 11:45:08 EDT Scripting, Blogging, Softwares... Georg Bauer: Comment on "Fun with XSLT": A XSLT script to translate Necho to XML-RPC serialization will be possible, but won't help with XML-RPC API at all. The reason being that...

Georg Bauer, you're right. The problem is that the data structures are slightly different in each language, and they use different terms and syntax etc...

The only thing that has to interoperate is the wire format. So we create first a RESTful API, then a tranformation to the XML-RPC wire format. Then each language can derive the correct data structures from that.

So the XSLT isn't a tool for everyday use, but more a precise way to describe what the XML-RPC wire format should be.

Sjoerd: so the XSLT is more like a formal spec. Ok, that's fine with me, as it takes out ambiguities that would be in there if people use natural language to describe formats. That's why I am a fan of discussing explicit examples and prototypes :-)