RE: XML.COM: How I Learned to Love daBomb

["Al B. Snell" <alaric@alaric-snell.com>]

On Tue, 21 Aug 2001, Michael Brennan wrote:

> RPC could never displace EDI technologies. It's too rigid and inflexible. If
> you want to adapt to a particular format over the wire, you have to write
> the source for your business services to match that format. Every new format
> requires the coding of a new interface.

So does XML! If you expect:

<order>
 <item>Food Sensor</item>
 <qty>10</qty>
 <send-to>...</send-to>
 <bill-to>...</bill-to>
</order>

And you get:

<request>
 <item-name>Food Sensor</item-name>
 ...
</request>

then you're shafted.

Of course, with XML, you can *add* extra elements and attributes and the
recepient gets to guess whether they are just irrelevant information it
can ignore, or some criticial information it can't process the order
unless it can understand. ONC-RPC avoids this multi-version issue by
putting version numbers on requests and having negotiation mechanisms for
implementations of different protocol versions to come to agreement with
each other; the client would ask the server if it supported the version
with the new fields in, and if not, it would either give up (if it *needs*
those new fields to be understood) or not send the new fields. ASN.1
extends this by allowing special added fields to be marked as such so that
the recepient can skip over them, just like XML does, but again this time
there are rules about what those fields can mean; if they are encoded as
later-version extension fields, earlier verion recepients are allowed to
ignore them. If they contain vital information then the sender uses a new
format that is not a backwards-compatible version of the old one, and the
recepient will barf, and in an interactive transaction that connection
will never get set up when transfer encodings are agreed upon if the two
ends cannot talk a mutually acceptable language.

> XML-based technologies can displace EDI, because they can easily support an
> adaptive layer that can map different XML structures into the same core
> business services.

So can other RPC technologies. Whereas in XML you might abuse XSLT to do
this (it's not what it's meant for and you can get burnt easily), with RPC
technologies you just write a different set of server stubs that accept
the requests and call your middleware functions. This is done in practice,
and it works fine.

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software