This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: How to do this in WD-XSL


Norm, first and foremost, the code fragment that you provided is XSL, or
more formally XSL-FO, XSL Formatting Objects [1]. XSL-FO utilizes XSLT,
but the converse is not true: an XSLT processor does not render XSL-FO.

Microsoft does not make understanding this easy, since in the MSXML
literature they use the term XSL to refer to XSLT. Let's be clear about
this: MSXML does not provide any support for XSL (i.e., XSL-FO).

XSL-FO is a stylesheet language for high-end rendering, such as the
print industry. If you are rendering to a browser, Cascading Style
Sheets (CSS) [2] is probably a more appropriate (and much easier to use)
technology. You can certainly combine XSLT with CSS, the former to
transform structure and content, and the latter to add styling to the
presentation layer. Additionally, CSS provides accessibility, allowing
the end-user to override presentation styling (e.g., allowing a color
blind person to use meaningful color combinations on his system).

On the matter of performing client-side transformations, the first
question is are all your clients using Internet Explorer for their
browser. If not, then using MSXML on the client side is not an option.
Second, if everyone is using IE, you can ensure that the clients have
MSXML 3.0 installed by requiring them to have installed IE 6.0, if that
is practical. Third, you do have the option of detecting whether they
have an specific version of MSXML installed (and provide an automatic
link to install it if missing) following the sample provided by Chris
Bayes' MSXML Sniffer [3].

There may not be much wrong with a page telling the client that in order
to use this feature she needs to install the Microsoft component, so
long as you do it in a way that the client can easily install the
component (e.g., you can put the CAB on your server and link to it).
Along those lines, if the client does not have MSXML 3.0, then they must
have IE 5.5 or below, and you may find other features in HTML that
require or are better supported in IE 6.0.

For performing a server-side transformations, how to do that very much
depends on your server technology. If you are using Microsoft servers,
the easiest way to perform the transformation is from within an ASP page
(or ASPX if you are on .NET). That is fairly straightforward, examples
abound. For performance you might need to cache the XSLT stylesheet
using the XSLTemplate class as described in my article [4] or the MSDN
Library.

I would avoid WD-xsl like the plague. It is obsolete. Microsoft and this
list no longer support it. There is absolutely no reason to be using
WD-xsl for a server-side transformation. Period. The configuration of
the server is under your control. Your server should be using MSXML 4.0
for performance reasons (four times faster than MSXML 3.0), and you
should code against a specific version. For that matter, on the server
you could be running any XSLT processor engine you want, because the
client never sees the XSLT, only the HTML produced by it.

Cheers,
Stuart

[1] http://www.w3.org/TR/xsl/
[2] http://www.w3.org/TR/CSS2/
[3] http://www.bayes.co.uk/xml/index.xml?/xml/utils/msxml_sniffer.htm
[4] http://www.perfectxml.com/articles/xml/XsltInMsxml.asp



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]