Re: [xsl] XSLT 2 processors

Subject: Re: [xsl] XSLT 2 processors
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 10 Feb 2012 11:44:52 -0500

On 2/9/2012 6:09 PM, Terence Kearns wrote:
Wow. Okay then. I guess it was fun while it lasted. I guess the
conditions aren't there anymore (for open source development of large

I guess Apache Cocoon's fate has gone the same way.

But Cocoon is still used, and the Cocoon users' list is still active.

I'm not arguing with the basic point, nor even with the questioning of Cocoon's development activity (which I don't track)....

Personally, I think the volume of code cutters has increased, and the
percentage of "casual" coders has greatly incresed. XSLT 1.0 probably
couldn't get traction with casual coders who could only think
procedurally and it scared them off - leaving no perceivable demand
for the next XSLT interation from the code cutting masses. So the big
coding houses like IBM, Microsoft and Oracle have lost interest.
Personally, I think that's a shame. That XML is primarily useful as
high-level web service data packets (competing with JSON) is a
misconception. It might be the reality that this is how the market
sees it, but "the market is wrong"  Living proof that market forces
don't follow technical superiority.

I think much of this is true, yet don't forget that XML and XSLT are still healthy (very healthy as far as I can tell) in the space for which they were originally designed, namely publishing systems.

Some publishing systems are content to stick with a single channel of output, such as print or the web. And if you're publishing only to the web, you can maintain your data in HTML and/or an HTML-facing CMS.

But other publishers can't do this, or they need to insulate themselves, to whatever extent possible, from technological changes in target media, and XML/XSLT allow them to do this. Or they need to find efficiencies and scalability in data interchange and data longevity that they can only get through a careful separation of concerns across their workflows, which XML/XSLT allows them to engineer.

If there's a significant part of the tech marketplace that doesn't even know this is going on, what does that say other than that the world is a big place?


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread