Hannes Wallnöfer : Yet another Weblog API proposal
"Maybe the most important design idea in this proposal is the use of structs for some central types of parameters. ... It is also possible that individual applications choose to extend specific struct types by adding members not defined in the spec. For this, I propose a scheme similar to that used in the MIME format in that non-standard struct members must have a name starting with "x-", e.g. "x-someMetaInfo"." Let me start by saying that I like doing XML-RPC and SOAP. But watching the weblog API conversation bloom like a thousand flowers and veer dangerously towards the nightmare that was/is RSS, I'm becoming less and less sure it's the right thing to do for weblogs. I'm not sure about this, but there are four(-ish) things all swimming around one another that have brought me here. First, everything on the .info blog (someday, I will finish migrating stuff...) is published as XML. If it needs to be published as HTML, the XML is piped through an XSL stylesheet. Secondly, Les Orchard states the obvious and asks why we don't just use basic authentication rather than re-inventing the wheel; file this one with the "why don't we just use SSL?" conversation. Third, my first reaction to Hannes' "filter" struct, for polling posts, was : Isn't that clever. My second reaction was : Can I add query fields and what about boolean searches and/or combining searches? My third reaction was : Wait a minute, I'm already doing this; I'm just not making public the results as XML. Finally, the willy-nilly extensibility of structs is useful for "busy developers" but it isn't really very helpful for people who are trying to figure out what it's all supposed to mean or writing tools to move data from one weblog to another. What I'm getting at here is that all this talk about the API is really just a lot of banter that avoids talking about something approaching a blog specific markup/DTD/schema. Or rather, it looks an awful lot like we're trying to arrive at a format by designing the functions for handling the format first. I know that XML was designed around the idea of not having to need a DTD. I have no problem with this. There are all kinds of instances where requiring that a DTD -- as an aside, I will just mention that I don't have any problem with schemas either; as soon as the W3C releases an Emacs xsd-mode, on par with psgml-mode, I'll start using 'em -- be written and parsed and validated is overkill; it is becoming apparent to me that weblogs are not one of them. If you've gottten this far and are becoming impatient for a Solution, you might as well stop reading; y'aint gonna find one today (if for no other reason than I'm about to step away from the computer, Aaron.) It will be obvious to readers, of late, that I like DTDs. They suck to write but if done properly they are flexible enough (mostly) to cut down on "re-inventing the wheel"-itis and offer room for inidivual users and instances to maneouver. Sjoerd Visser's opml:foo attribute hack is a good example. It took 5 or 6 email messages for he and to realize that we were both on the same page. At first, I misunderstood what he was saying and thought he wanted some kind of magicopml: attributes to be added to the XML spec itself, which struck me as equal parts widhful thinking and slippery slope. What he really wanted was for people to either explcitly include, or provide people with the option to add via parameter entities something along the lines of...
<!ENTITY % opmlText "CDATA #REQUIRED"> <!ENTITY % opmlLink "CDATA #REQUIRED"> ... <!ELEMENT foo (yadda,yadda,yadda)> <!ATTLIST foo %opmlText;>...which then lets him massage any XML document into OPML and vice versa. Parameter entities, or whatever the suitably nightmarish namespace equivalent is for xsd are, allow people to say "yes, and..." and provide context for tools to validate and try and do the right thing. So long as you're okay that the various tools may play fast and easy with your more esoteric changes, everyone is happy. So, while I'm not quite ready to jump on the REST bandwagon, when I look at everything I've just said in combination with clever hacks like this browser-based xml content editor I start to wonder. But I digress...