Lists Home |
Date Index |
----- Original Message -----
From: "Jens Jakob Andersen, PDI" <email@example.com>
> 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
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 suck. 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">
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
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.
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 ).