[
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?
len
From: owner-cg@cs.uah.edu [mailto:owner-cg@cs.uah.edu]On Behalf Of Arun
Majumdar
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 ]
Hi,
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> ...
Language=CGIF
#CDATA ... <!--- stick all your code for
micro-parsing here ... --->
.....
</Microparser>
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,
Arun
> 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.
|
