> -----Original Message-----
> From: [log in to unmask] [mailto:[log in to unmask]]
> Sent: February 18, 2000 4:07 PM
> To: [log in to unmask]; [log in to unmask]
> Subject: Re: Why XML is a waste of time

> If anything, it's more of standard
> layout protocol. Don't get me wrong, there's nothing wrong with that, but
my
> original contention stands: for most applications, it's overkill. A
simpler,
> even more application-specific tagged file format would probably be easier
to
> work with and much more efficient to process.
...
Hmm, you clearly understand what XML is, but I guess I don't see why you
can't understand why having a "standard layout protocol" is a good thing.
The problem with everyone devising their own format is that you can't count
on any two having the same characteristics.  By basing formats on XML, you
gain benefits like standard escaping mechanisms, allowance for international
characters, etc.  This allows one to write general purpose processing
software that processes all manor of XML files.

If nothing else it also makes it easier for two parties to agree on a data
exchange format.  If you and I wished to exchange data, we can start by
agreeing that the format is XML.  Now we're clearly not finished, but we
have taken a big step in the right direction and we've cleared a whole bunch
of hurdles like what a tag looks like, how escaping is done, how to indicate
different encoding schemes, etc.  I think this alone makes it worth getting
to know XML.

One of my favourite quotes from Tim Bray is that XML is the "next generation
of ASCII".  I think this analogy holds up very well.  When we agree to
exchange data in ASCII we're really agreeing on a whole range of issues
(what characters we allow, what byte-code corresponds to what character,
etc.).  You layer XML on top of ASCII (well, Unicode really, but you get my
drift) and you've agreed on all the additional issues I mentioned in the
paragraph above.  ASCII is a protocol, XML is a protocol.  Yes it might be
over engineering for some tasks, but I think that in most cases the over
engineering will pay dividends down the road.

> PS: BTW, in the telnet address phonebook example:
>
>>             TelNetAddr1 = 192.168.1.1
>>             TelNetAddr2 = 209.181.113.217
>>             TelNetAddr3 =
>>             TelNetAddr4 =
>>             TelNetAddr5 =
>
>each line is essentially a "line break". Each line is being loaded into a
>Windows pick list, in order, by number. The number of the slot represents
the
>frequency of usage, with the number one entry being the last that you used.

>Nonetheless, the scheme shown above could just as easily be meant to
>represent the lines on a order header.

Yes, you're correct, technically that does handle line breaks, but I would
argue that the relationship between the lines (that they all form one
object) is not as obvious as they would be in an XML file.  In your example
the coupling of the lines is very loose (they are related by name).  I would
argue that the XML equivalent would be easier for a general purpose
processor to handle.

e.g.
<TelnetAddrs>
    <Addr>129.168.1.1</Addr>
    <Addr>209.181.113.217</Addr>
</TelnetAddrs>

In the XML example a general processor can see these two addresses are
clearly part of the larger unit.  In your example, the same general
processor might have trouble distinguishing that TelNetAddr1 is not related
to TelNetAddressingScheme.  Sure it could be enhanced to do that, but my
point is that there are a lot of subtle benefits to the XML syntax that are
there by design.  XML is *not* a waste of time.

Rob