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

[Jeffry Smith]

On 11/14/06, Kevin D. Clark <kclark at elbrysnetworks.com> wrote:
>
> 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.


Another big reason is the reason SGML (predecessor to XML) came about
- separating content from presentation.  IBM (some company that
actually DOES innovate) developed it and sold it to the DoD.  Concept
- you have documents that will be displayed multiple ways (on-screen,
printed, etc).  However, you don't want to rewrite them each time.
SGML (now XML) separates the two.  In SGML you had 3 parts:  the data
with markups for structure, a DTD that described the markup allowed
for a given kind of document (another reason for it - ensured
consistency of the documents), and a presentation element.  The
presentation element would be different, depending on the medium.  So,
by writing one document and marking it up, it would be usable on
multiple display formats.

As mentioned, it's also good for ensuring consistancy.  And it's
portable - based on text.

Probably more reasons, but that's oen that I remember.

jeff