Cart
[Home] [By Thread] [By Date] [Recent Entries]
----- Original Message ----- From: "Jens Jakob Andersen, PDI" <jens.jakob.andersen@p...> > I was at a web-developer meeting with 5 dot-com survivors > (none got rich, real survivors!), and we talked about XML. > Seemed that as long as it was poserpoints, it worked out fine. > But the moment they started to implement solutions, > suddenly everybody had to code and code and code, > since suddenly XML shows all that it is lacking. People think that because XML is easy to write - it should be easy to process. It takes some guts to understand ( and tell ) the truth: XML is just simply hard to process. It is harder to process, than CSV, because, for example, there are no convinient XML bindings for general-purpose languages out there. SAX is just a lexer and DOM is too low-level. Not talking about the storage, but about 'processing only'. Smart people ( and those, who avoid low-level SAX / DOM *are* smart ) usually start abusing XSLT ( kinda "the only scripting language that provides a nice 'binding' to XML" and 'hey - it is blessed by W3C as a standard!' ). The problem is that XSLT is not at all a general purpose language ( and has no reasonable way of embedding it into general-purpose language), so resulting XSLT-based solutions also [expletive deleted]. Either people write crazy ( unreadable ) recursive call-templates or they use Java extensions - that results in their code being split between the XSLT stylesheets and the Java code. Verrry sweet mess to support ) Some *very* smart people have recognized that they are better to avoid extending XSLT and better to build the pipelines. But if you build a pipleine on SAX, then again - no reasonable binding - and again - welcome to code your 'compiler' on top of SAX lexer for every component that you want to plug into the pipeline. And keep hearing that 'SAX and DOM are the standard APIs to process XML'. Sounds nice on paper, of course. > David even suggested: "XML is definately not new. > There is nothing that hasnt been doable for eons with RPC and Ascii." Sure. And it is kinda more convinient to use CSV, because CSV-based world has developed a sophisticated, convinient, universal binding mechanizm, called "regular expressions". Regular expressions are not blessed by W3C, sure. > XML and supporting areas (Xpath, Schema, XQuery, SOAP etc.) > lacks a lot of stuff, when you get down to doing hard work. Doing *any* work. Just think about writing some trivial snippet that would take some XML file, check for the tags <client name="John Smith"> </client> and validate the names of the customers against your legacy SQL table ( if this sounds really easy ( and it is ) - think about more sophisticated validation, when some children of <client> are involved). No general-purpose XML binding means 'everything in this world should be XML' - that is just not true. And it will never be true, BTW. Or try rendering a real-life financial XML report with XSL ( it may take a 100 of pages, you know... ) Wanna store a big number of XML documents, or wanna store a huge XML document? Welcome to the *real* challenge ( and that challenge would not be relevant to 'DOM' or 'SAX' or 'XSLT' ) > 2. What is needed to make XML usefull? Re-factor it. Re-position it. The *really* funny thing is that's *exactly* what happens already ! My prediction is that in next years OASIS would take more and more power over the XML world and XML as we know it ( some set of papers on W3C website ) is almost dead. > JJ (Heading for my asbestos anti-fire bodysuit.) One month ago I talked to VP development of some startup. They've invested plenty of resources into XML. What he said was : "I hope they'l make it work in version 2, because version 1 just can not work for us". Still, I belive that : a. XML was a right step after SGML, in a sense that Java was a right step after C++. b. XML is definately not the last step and some parts of XML++ are already developed by: XPathScript, XSLScript, YAML, Chunks, PXML, RELAX NG and other marginalia, that would never get blessed by W3C, but will just ... work ... Like it was with perl, linux, UNIX and I think anything else. XML has it's place : 0. Great social impact. Very important. 1. One source -> N media with XSL - OK. 2. Verbose configuration files - OK ( but with some 'DOM trouble' ) 3. Import-export - OK ( but mostly because of political side ) However, I think that building reasonable, scalable, supportable XML-based solutions *requires* at least 2 years of experience using *plenty* of XML tools and technologies and I can not believe that there is enough people who : 1. Have such an experience 2. Even in case of (1), can explain to some VP ( who've had a negative experience with XML, which will be the case with P = 90% ) that to keep investing into XML is a reasonable thing to do. So. 1. XML is a mess. 2. XML was a right step. 3. There is a fork down the road, because it seems that the organization that has successfully handled 'version 1' can not handle 'version 2' *and* nobody can own the 'idea of markup language' ( or better to say, nobody can own the 'hashtable' or 'tree' ). Yes, RELAX NG is better, than XSD and I still feel that in some sense, the Schema *is* the cornerstone ( like it was in SGML ). Rgds.Paul.
|
