XML quote Re: Meeting Notes: SLUG Mon 14 Nov - Google Earth and everything else

[Kevin D. Clark]

Paul Lussier writes:

> Is there anyway we could foster this into a real discussion on XML,
> what it is, what it's used for, why it's
> good/bad/evil/sucks-rocks/better-than-sliced-bread ?

Well, everybody has their own view on the world.  You need to
understand where I stand before you understand my perspective.

I occasionally design (and implement) non-trivial communications
protocols.

When you're designing protocols, you need to get the protocol to be
expressive enough in order to transport the information you need over
the wire.  Of course, this should be obvious.

What isn't necessarily so obvious is the fact that the entire time
you're designing and working with the protocol, you've got to be
thinking to yourself "how do I design this protocol to be
future-proof?".  At some point you need to make the protocol flexible
enough so that implementations of one version of the protocol can be
backwards-compatible and interoperate with previous implementations of
the protocol.

This is the kind of problem that can make you lose a lot of sleep at
night.

One of the useful ways to think about a protocol is to think about it
in terms of the information that is carried in each logical message
(the semantics) and on the other hand, how each message is logically
expressed/encoded on the wire.

XML encoding is useful here.

Speaking very generally, suppose I have a message that is encoded like
this:

   <foo>
   <color>blue</color>
   <height>1.3m</height>
   <fav-dessert>pie</fav-dessert>
   </foo>

Suppose this is version 1 of the protocol.

Now suppose in version 2 of the protocol we want to add some more
properties:

   <foo>
   <color>blue</color>
   <height>1.3m</height>
   <fav-dessert>pie</fav-dessert>
   <weight>22kg</weight>
   <fav-movie>Brazil</fav-movie>
   </foo>

By using XML encoding, a version 1 peer's protocol implementation
isn't so inflexible that it bombs when it sees these extra fields --
it can, for example, choose to ignore these extra fields.

Contrast this behavior with some other, fixed-field protocols (how
about TCP for example).  How would you arbitrarily add a field to such
a protocol?  (answer:  not very easily)

When you're working on a rapidly changing product that involves a
custom protocol (or, alternatively, a protocol that you merely wish to
extend), having flexibility like this can be very useful.


Anyways, that's my perspective.

Regards,

--kevin
-- 
GnuPG ID: B280F24E              Never could stand that dog.
alumni.unh.edu!kdc                   -- Tom Waits