FW: XSLT 2.0 and CMS

Hi guys, I'm a vendor here responding to a statement of a couple months ago
that I found when I searched for "Ektron" in the archives.

Robert Koberg wrote:
> In ektron's case they have hardcoded a dependency on MSXML's processor.
> This means that those stylesheets cannot be used by other XSL processors
> -- one of the great benefits of XSL.

This isn't true at all.  Our CMS product can use external XSLTs you've
created yourself in XMLSpy or whatever development tool and we also have a
WYSIWYG layout tool that auto-generates an XSLT.  In both cases we're using
standard XSLT.  The auto-generated XSLTs don't use <msxsl:script /> or any
of the custom MSXSL extensions.  So an XSLT used in or created in Ektron
CMS300 can be used outside of the system.  For example, you could pull
CMS300 XML content through our Web Services API to a JSP page on a remote
Linux server and transform it with the CMS's auto-generated XSLT using the
Apache Project's Xalan parser.

In fact, our eWebEditPro+XML editor that provides the user interface to
create XML content is sold separately and can be used in any server
environment - Linux, AIX, Solaris, etc.  (although the client environment
must be Windows).  So that portion of the system is also designed to be
usable with any XSLT processor on the server or any other XML-processing
technology.  (In addition to auto-generating a standard XSLT it also
auto-generates a standard XML Schema, by the way.)

And furthermore, the code in the CMS that runs the transform when XML
content is displayed to the web is in the open source layer (centralized in
a single function, in fact).  So you could hook in your own XSLT processor,
any one you want that can be used with the scripting language that you're
using (ASP, ASP.NET, Cold Fusion, and PHP are supported).

I would actually say that we're much better for permitting use of any XSLT
processor than any of the pure open source software I've seen.  I mean, try
setting up any of the Apache project stuff to use MSXSL and you'll be
changing alot more than a single function.

-----------------

While I'm at it, my two cents on XSLT 2.0: I've really liked many of the
features I've seen in XSLT 2.0 and I was quite disappointed when  I found
that Microsoft doesn't seem to have any intention to implement it in the
upcoming .NET System.Xml 2.0.  I have tried many of the XSLT 1.0 solutions
that Robert mentioned in his posting and I've usually found them either
clumsy or downright unworkable (with the exception perhaps of the Muenchian
method).  I guess I'll have to start playing around with Saxon. :)

Tim Denby
Sales Engineer, Ektron Inc.
[email protected]


P.S.  It just occured to me that Robert might have been referring to the
pre-processing or post-processing of XML content when the user edits it in
the eWebEditPro+XML editor tool.  This is done internally to the editing
tool (on the browser client system, in fact, and is normally handled
entirely by our system without developer intervention) and does use MSXSL as
well as a few other proprietary components.  But this interface is also done
in the open-source layer of the product so you could add additional
processing steps with any XSLT processor.