OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   The XML Backlash

[ Lists Home | Date Index | Thread Index ]

Part of a discussion on the Conceptual Graphics list. 
Arun is reflecting a frustration I hear about XML from 
locals as well.   Part of this is a frustration with 
the community and it's insistence on XML as a panacea 
on the networks.

Are we at the emergence point of an XML backlash?


From: owner-cg@cs.uah.edu [mailto:owner-cg@cs.uah.edu]On Behalf Of Arun
Sent: Friday, December 03, 2004 9:12 AM
To: cg@cs.uah.edu
Cc: jmc@cs.stanford.edu
Subject: Re: CG: XML [ from trenches of The Real World ]


Murray, it is quite easy for us all out there to argue about this when few 
are actually in the trenches doing the work. I hope that my comments at this

time will point out where I am personally situated, that may be of value to 
you and to others regarding XML as well as CBCL.

I am currently under contract for one of the country's largest Telcom 
(wireless, land line, and fibre-optics) infrastructure companies on a 
current issue and it regards XML.  Your analysis is unclear to me and I do 
not know on what basis you made the comments other than the cited secondary 
or tertiary references.

Here are some points from my perspective:

1)  Does anyone out there really know whether CCBL is better or worse than 
FBCL or BPEL or JPDL etc... or has business changed that much in 2000 years 
where a "buyer" and a "seller" are somehow now identified differently and 
the concept of a "medium-of-exhange" and its "transaction" are no longer 
valid?   Would CBCL, micro-parsed as mentioned earlier, make a better/worse 
business-process integrtion language?  Who out there is qualified to answer 
this?  Are you?

> I'm not even sure what you're advocating here. Does anyone
> actually think a step back to CBCL would be either an
> improvement or could possibly, possibly occur in the real
> world?

What do you know about what it means to take a step back?

HERE IS A QUOTE FROM McCARTHY"S SITE:   << Developing an expressive CBCL has

proved unexpectedly difficult. Even concentrating on the idea of a purchase 
order doesn't easily lead to defining formats that permit expressing all 
that should be possible to include in a purchase order. The problem is that 
every aspect of the purchase order such as the delivery method or the terms 
of payment seems to admit infinite variation and elaboration. It is a 
semantic feature of natural language that this elaboration is possible. The 
problems do not at all stem from the rigid list syntax of CBCL, which after 
all resembles the result of parsing a natural language text. The problems 
are in the semantics, i.e., in specifying what should be expressible. >>

The issues of XML are entirely secondary and downright irrelevant, 
especially today, when you consider the real import of the preceeding paper 
on CBCL.  CBCL is a viable approach as much as is FBCL or BPEL or any other 
proposed format:  there are no leaders in this game today.

2) (a) We tried XML messaging to handle the interfaces that are mandated 
under law (for Telephony standards of performance (metrics)) to provide a 
certain time-response and a certain set of performance characteristics. XML 
used up the current bandwidth and the methods of using .NET instead of CORBA

failed miserably (the system still and continues to run under CORBA).  Some 
on the team argued it (XML's failure) was lack of faster machines and other 
argued immurity (of SOAP, of .NET etc...).  I noted "Godel Theorem" effect 
taking place where as the machines become faster, the semantics deeper, the 
messages longer, the compression higher, you need more and yet still faster 
machines because the loop repeats --- why ?  Cheap, lean machines is what 
powers the world.  If you walk into a bank, they have those nice flashy 
Windows boxes ... on the back end, they connect through an emulator to a 
mainframe with Class-B security, to a system that is, quite frankly, 
un-hackable and without the plague of viruses or the tower of Babel and XML 
Babble. These machines that run (VM, MVS and other flavours) use 
micro-parsing (today) on the emulator side and there is speed.

(b)  Using XML with plug-in micro-parser has proven very effective and 
advantageous. Here is a pseudo-code like sketch:

Example:   <Microparser> ...
                        #CDATA ... <!--- stick all your code for 
micro-parsing here ... --->

This provides a "plug-n-play" approach to microparsing using called-in 
components and is the way it is done for high-speed network processing I 
have worked on.

3) As to compresssion:  I have created compressed index-tables for indexing 
compressed XML for high speed-message routing in a real-time communictions 
subsytem --- the management at the time I did this had the typical and naive

"take-it-for-granted-we-can-always-get-faster-hardware" and, modern networks

are faster ...eventually, they too learned that the panacea of XML and the 
attendant mass of emerging vocabularies whose syntax and semantics are very 
poorly engineered from a linguistic perspective, ends up being a corporate 
"intra-domain-specific-language" ... so why bother with XML in the first 
place.  When you do have a VOIP system, the last thing you want is *any* XML

because the TAG overhead and transforms DOES make a difference.

4) XML is used in service-oriented systems with *success*: none of them are 
time or mission critical. Yet there are significant problems with using XML.

For people out there who make youthful comments and have not faced a 
real-world CEO that is blustering his IT department, the issue of trying to 
explain the problems of XML in, for example, Business Process Management, is

like trying to explain to a new born baby how to drive a car!!!

The worst is when babies are actually hired because of babble and put into 
the driver's seat.

Consider BPEL versus BPML versus JPDL (which ended up using embedded JAVA 
within the actual XML code) versus XRL etc... I have written a Business 
Process Kernel for a company that is in deep sh*t because they followed the 
advice of "babies" and consultants that migrated from the "beautiful 
academic" world and fell flat in the real environment.  Nothing works like 
one thinks it does on one's homely PC or a 100 computer "academic" network.

The laws of large networks are very different and the problems, a-priori, 
cannot be formally analyzed by any means known today to even approach 
predictive performance metrics... XML may have a butterfly effect in one 
system, and cause failure (example, telephony) in another and yet may in 
another system prove to be a real boon (example: XSLT transformation within 
a system for business process management).

You simply do not know.

5) The remarks about a "bygone" era indicate a youthful position and not the

real world where it is 80% "bygone" code and most "critical" infrastructure 
is "bygone" that is actually running the show today.  By rushing headlong 
into XML, whose life-span is rather short (it has not been around for 30 
years) we are rushing like fools where angels fear to tread ... and we do 
not understand the full effects of XML'izing or when things should be 
XML'ized, and failing to understand the value of terse, under-specified (and

no! under-specified is NOT meta-data, it is "constraints") although WSFDL 
recognizes that in its design, most XML systems and system-designers lead 
their companies into the xml trap of believing that what is in your head (as

terms, glossaries, syntax and logics) translates into a one-to-one mapping 
with semantics that modern cpu's can handle as if "they" know what your 
"intention" was ... and that problem is one that is leading us astray with 
layers and layers of XML that is, in the so-called moder iterative process, 
iteratively deepened with complexity and obfuscation.

When it comes to networks, security and many other issues, I urge you all 
out there to consider domain specific languages (which is what XML is mostly

used for) with component-oriented micro-parsing techniques embedded with XML

.... example: parse CGIF (from its linear form embedded in an XML "envelope"

using only the CDATA form) at a host into KIF and then re-transmit to 
another using another microparser: this yields a thin middle layer of 
transport code (XML) ... so you have two components (one for CGIF and one 
for KIF) instead of one component for both, without the thick middle layer 
of transport code.  Look at thin-client server architectures and mobile 
phones ... most of it is trimmed down to the bare minimum and most 
inter/intra device messaging uses customized operating-system specific files

(look for example at Symbian SIS messaging and bluetooth ... ).

6) I love the buzzwords about "meta-data" and operating systems.  The AS400 
was an operating system with meta-data via its inbuilt data management 
(DBMS) environment.   <begin_quote> DB2/UDB for OS/400 is one of the most 
widely used multi-user RDBMs in the world. It includes such essential 
features as referential integrity, stored procedures, triggers and two-phase

commit, to provide the capabilities required to support mission-critical 
applications. DB2/400 supports ANSI SQL, DRDA, DAL CLI and ODBC. Also, 
DB2/400 is integrated into the hardware and operating system, not an add-on 
layer.  </end_quote>

We have a lot to yet learn about that machine before trying to re-invent 
things.  The Symbolics LISP machine was yet another example.

This comment does not indicate that we should *not* try to push meta-data 
in, but to understand *what* is it used for *intentionally*.   Do we want an

XML O/S --- is that not the end-game and if it is, what does that *really* 
do for us? Does it really reduce the barriers to comunications between 
systems or does it make "autonomic" systems more likely and easier to 
engineer or is it just more bloat?

I hope this position sets out a wider playing field where we can determine 
the middle-ground : I do not know the answer and I make no claims about what

is or is not: only my very personal but professional experiences are 
presented here with respect to what I face daily.

These are my comments from the trenches.

Now I have to get back to that XML code I as working on (PNML - Petri-Net 
Markup Language) which is my domain-specific language and to 
Enterprise-Architect (from Sparxx Systems) so I can export my UML models 
into Rational-Rose using XMI and I can export parts of my report to 
OpenOffice using XML again ... although that is proving a little harder ( 
http://xml.openoffice.org/) and increasing my own persona workload.

Thank you,


> John F. Sowa wrote:
>> The question of XML "bloatware" has been discussed here
>> before, and I just wanted to mention a couple of relevant
>> articles.  The first is from eWeek:
>>     http://www.eweek.com/article2/0,1759,1732909,00.asp
>>     Users Adjust to XML Tax on Networks
>> Following is an excerpt:
>>     As much as XML use grows for projects involving
>>     document and data manipulation, enterprises are
>>     finding that the benefits of XML are not without
>>     associated costs.
>>     Specifically, the extra processing power required
>>     to handle parsing and processing XML can be a strain
>>     on systems. In fact, according to a report issued
>>     this month by ZapThink LLC, XML is starting to choke
>>     the network from a bandwidth and processor perspective.
>>     "Network traffic increases due to the increasing
>>     quantity and size of messages, both XML and non-XML-based,
>>     will tax the existing corporate IT infrastructure to its
>>     limit," said Ronald Schmelzer, a ZapThink analyst in
>>     Waltham, Mass. "Network administrators find they must
>>     devote general-purpose application servers, network
>>     equipment and messaging infrastructure to simple message
>>     parsing, handling and routing functions, while precious
>>     few resources remain for executing core business logic."
>> XML (along with GML, SGML, and HTML) is an excellent language
>> for formatting.  It is also a good language for embedding
>> other languages with tags such as <SCRIPT...> and </SCRIPT>.
>> But as a universal syntax for business processing dialects,
>> John McCarthy had a better solution back in 1982:
>>     http://www-formal.stanford.edu/jmc/cbcl2.pdf
>>     Common Business Communication Language (CBCL)
>> For implementing other language formats, CBCL has more power,
>> greater flexibility, and far better readability than XML
>> with a vastly more compact and more efficient format.
>> The only claim that anyone has ever made in favor of XML is
>> the availability of tools for parsing it.  But CBCL could be
>> parsed with only two operators:  for any CBCL expression X,
>> (CAR X) produces the operator, and (CDR X) produces the
>> list of arguments.
>> It's not too late to switch.  PHP has demonstrated that
>> a good language that solves an important problem can very
>> quickly become a de facto standard -- even without a
>> consortium to back it.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS