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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XML=WAP? And DOA?

[ Lists Home | Date Index | Thread Index ]


----- Original Message ----- 
From: "Jens Jakob Andersen, PDI" <jens.jakob.andersen@post.dk>


> 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 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">
</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.



  • References:



 

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

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