Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] The XML Backlash
 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@c... [mailto:owner-cg@c...]On Behalf Of Arun Majumdar Sent: Friday, December 03, 2004 9:12 AM To: cg@c... Cc: jmc@c... 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
