[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML as generic villain

• To: xml-dev@l...
• Subject: Re: XML as generic villain
• From: Mike Champion <mc@x...>
• Date: Thu, 16 Jan 2003 00:57:51 -0800 (PST)
• In-reply-to: <a05200f01ba4b0b5b01ee@[192.168.123.136]>

--- Rex Brooks <rexb@s...> wrote:

>
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2908614,00.html
>

As poorly written and misinformed as the article
surely is, I find the analogy of video cards
intriguing: text-oriented video systems were
overwhelmed by the demands of GUIs and graphics, and
the vendors threw hardware at the problem to make it
go away.  Current networks are oriented toward
protocols whose "visible" information is confined to
well-defined header fields, but XML makes the entire
content of the message potentially visible to routers,
caches, firewalls, etc. Not only that, the fact that
many XML applications (at least those created by
default in VS.NET, etc.) "tunnel" the Net protocols
creates a *need* for such intermediaries to understand
the XML content of an entire message in order to do
their job.  

Assuming that the RESTifarians don't persuade the
world to just Not Go There, I can very easily imagine
network admins being overwhelmed by XML in the very
near future, much like 1985 video cards were
overwhelmed by GUIs.  Why *not* offload as much of the
grunt work of XML network processing to specialized
hardware? 

That's not to say that I believe that the current
state of the world requires this or that the current
products provide adequate solutions, only that I don't
believe the situation is laughable.

• References:
  • XML as generic villain
    • From: Rex Brooks <rexb@s...>

• Prev by Date: RE: XML as generic villain
• Next by Date: Re: XPath validation against a schema rather that against an instance
• Previous by thread: Re: XML as generic villain
• Next by thread: Encoding Problem
• Index(es):
  • Date
  • Thread