Comparing the "Economics" of REST and RPC

Roy T. Fielding fielding@ebuilt.com
Thu, 16 Aug 2001 15:01:23 -0700


> I'd really like to read the past history, but I missed it as it went by
> --- FoRK has had such a high noise level over the last few months that
> I've pretty much ignored everything.  Could you provide URLs for one or
> two of the messages that do a good job of explaining how XML introduces
> these hundreds of hidden dependencies?  I've seen your arguments about
> how HTTP provides more application-level semantics than XML, how SOAP
> uses HTTP as merely a framing protocol, and how parsing XML is less
> efficient than parsing HTTP, but I don't really understand about the
> hundreds of hidden dependencies.

It comes from the application design, not just XML itself.  XML has the
general capability of supporting external entities, DTDs, stylesheets,
schemas, and transforms.  Each of those in turn consist of modules composed
from other entities, DTDs, stylesheets, schemas, and transforms.  If you
are working within a controlled environment, such as a word processor, then
these relationships can be managed.  If, however, you receive an XML message
with such a network of dependencies required to completely understand
its processing (not its semantics -- just how to process the message for use
by other systems that will consume it), then not only do you get tied up
in a complex mechanism for processing, but unless the relationships have
been flattened and embedded within the application they become a tree of
potential points-of-failure that belies the simplicty of the <tag></tag>
encoding of the message.  In order to avoid that, programmers are forced
to flatten and embed the dependencies within the app (in other words,
restrict the syntax to a specific version), which defeats the extensible
part of XML and the only reason beyond buzzword-compliance to use it
in the first place.

....Roy

p.s. I unsubbed from fork a while ago so that I could get some work done.