My predictions for XML: the Future of XML

[erich brant]

My predictions for XML: the Future of XML
1) XHTML in 2 years will fully replace HTML 4.0
2) XHTML for IE and Netscape in the future will
be 95% compatible.
3) Other XML languages ( schema, dtds's etc...) will about
70-80% compatible with IE vs Netscape.
4) Parsers written in different programming langs. will
not "parse" and be 100% pure xml.
5) Java will be the number 1 lang. for working with XML
second will be perl or php.
6) C# will take years to replace VB but I is 6 years late
to market vs Java thus will never replace java or C/C++.
7) Python will replace Eiffel/Smalltalk/Objective C
8) Perl will still be number 1 for CGI , but php will be
a very close second.
9)Java will have a legal doc. similar to GPL.
It is already written and called SIZZLE.
10) Linux/apache on the server side will be number 1
when writing XML on the back end.

Learning from the past: How XML may share the same fate
as javascript and DHTML.

I think IE 5.5 is better then netscape 6.01 But It is not fair
for one browser to rule the web. I wish each was 50/50% of the
web so they would be forced to have javascript and DHTML that
is 100% compatible. With either one being more popular javascript
and DHTML will never be 100% compatible between the 2 products.

The scary thing is that XML will very likely share
the same fate as javascript and DHTML. Being , not living up
to its potenial because of incompatible browsers and parsers.
This is my prediction ! for the next 5 years

[Ajith Kallambella]

I am not really worried about XML support by different browsers. One has to look at XML as a pure data format, it is not a replacement for HTML and so browser support is hardly an issue.
Lack of standardization will hinder the growth of XML for atleast another year or so. While W3C churns out new specs, vendor support will continue to grow, but in a highly non-standardized way.
More frameworks/language extentions ( such as JAXB) will evolve that will greatly reduce "hand-coding" XML documents.
Last but not least, it would be a crime to think XML as analogus to DHTML or JavaScript !! They are not similar or complementary technologies.

[Holger Prause]

The scary thing is that XML will very likely share
the same fate as javascript and DHTML. Being , not living up
to its potenial because of incompatible browsers and parsers.
This is my prediction ! for the next 5 years
I also think so , but when u use xml / xsl with browser , its you own fault !
I think using XML / Xsl in a Browser makes the same sense as writing applets :-(
There are alternative for using xml / xsl in your Browser
-> Xerces / Xalan and the many other good parsers and XSL Prozessors
Its so easy to make Html Output to the browser using Xalan / Java Servlets.

XSLTProcessor processor = XSLTProcessorFactory.getProcessor();
processor.process(new XSLTInputSource(new FileInputStream(xmlPath)),new XSLTInputSource(new FileInputStream(xslPath)),
new XSLTResultTarget(res.getWriter()));
thats all
why writing 80 % w3c Conform Xsl Stylesheets just for that reason that it runs with Msxml Parser, and then writing the same stylesheet for Netscape(Netscapt still has no Xml Support or am i wrong ?) ?

[Elisabeth Van]

Holger,
Could you please tell me what version of Xalan you are using? I have searched the API docs and can not find XSLTProcessor, XSLTInputSource, or XSLTResultTarget.
I'm having a devil of a time trying to use a servlet to do exactly what you described.
Your help (or anyone's) would be greatly appreciated.

[erich brant]

www.netscape.net version 6.01 has xml support but I do not know
"how much " Also, I should have been specific in that
XHTML is a lang. of XML , thus for browsers I fear that
XHTML support will be divided like DHTML and Ecmascript vs
Jscript (MS).
Also because anyone under the sun can write an XML parser
(Non-validating or Validating), their is no organization that
forces XML and its parsers to be 100% standard. Thus
one can conclude that someone (I wonder who?) will take
advantage of that fact ! The w3c is not legally aka
via lawsuits, enforcing ECMA script or DHTML.