From: Jeff Bone (jbone@jump.net)
Date: Thu Mar 16 2000 - 14:48:15 PST
Here's my thinking on "The DTD Problem" vis-a-vis something like XML-RPC.
Dan Brickley wrote:
> [trimmed Dave from cc: list as he seemed baffled by being there]
Aren't we all?!? ;-)
> That said there's a definite danger of creating a chaotic babel; we're
> at risk of death by 1000% DTDs already with document and data
> formats.
I think XML-RPC gets you something like a solution for that. Arguing about a given
domain-specific DTD can be a losing and lenghty proposition. XML-RPC avoids that by punting
application-level semantics up the chain, and simply providing a common syntax and type
system / representation for arbitrary data structures in the context of request-responses.
While that doesn't exactly inspire interoperability, it at least makes it easier to
interoperate on a case by case basis. Instead of, say, 5 buddy list developers agreeing to
support some as-yet unspecified format for presence profiles and then spending years trying
to agree on what that is, they could just agree on using XML-RPC, and then partially map
whatever into that, ignoring fields they don't understand. Not perfect, sure, but it avoids
the "we can't start until there's consensus" problem. Consensus building becomes an
iterative process, with increasing levels of interoperability along the way. IMO, it's
easier to argue interfaces and datastructures then framing protocols, packet structures,
state machines, namespaces, and all the other stuff. With HTTP-as-RPC, you at least get to
inherit a lot of that, and it puts you in the more-familiar (to app developers) domain of
interfaces and data structures.
This argument is only valid -wrt- data. There's a separate problem which Dan calls out with
regard to methods. But again, the ability to quickly and iteratively come to agreement on
method names and semantics within some kind of an XML-RPC-like framework should be much
easier than fighting a whole separate protocol battle.
> If people start inventing 1000s of new methods on Web objects
> too, without well thought through mechanisms for mixing and inheriting
> from others' HTTP extensions, it all looks worryingly chaotic.
I guess I'm hung up on semantics, but I don't view XML-RPC as an "extension" of HTTP, rather
as an application of HTTP. If you're talking about "methods" at the HTTP level, i.e. GET /
POST / etc., then I completely agree with you. I'd even say that we're *already* at the
"babble" level with everybody trying to cram new methods and semantics into evolving HTTP
specs. If however you mean that all objects that talk to each other over HTTP must have
their interfaces and communication semantics embodied in some standard --- i.e., XML-RPC is
bad because it lets implementors create "non-standard interfaces" on top of HTTP --- well, I
wouldn't agree with that. I guess my argument, simply stated, is against the notion of
"application protocols" as they have traditionally existed in the IETF. No need for that, we
should layer the abstraction space and move the bar up. Standards bodies can't move fast
enough for app developers. 1-1 interoperability is much more achievable outside the IETF
process, and iteratively applied between multiple parties can get the same results even
quicker. I'm not *against* the IETF or standards; I've just come to the conclusion that
most expeditious way to get an RFC in place is to have dozens of independent implementations
interoperating *first* before you go to the IETF. The IETF is a *lousy* place to do
design-by-committee, which is a lousy process anyway.
Sigh... on to slightly more technical discussion of the 1000s of methods problem.
I've waffled through the years on CORBA. Here's my current viewpoint: IDL and the concepts
it embodies are gems, but the implementation and the rest of the specs are pretty much
navel-gazing crap. There's a danger in building in *too much* at the semantic level, and the
rest of the specs all constitute a sort of mass semantics for CORBA systems.
XML-RPC --- or something like it --- really needs three things to address the "babble"
problem. It needs reflection: every site / system that exposes its interfaces through an
RPC-over-HTTP protocol needs some way for others to interrogate and discover those
interfaces. This implies the second and third things it needs: an "IDL" of sorts, and
something like an interface repository.
$0.02,
jb
This archive was generated by hypermail 2b29 : Thu Mar 16 2000 - 14:53:03 PST