RE: XSLT 2 backwards compatibility (wsd: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span)
Subject: RE: XSLT 2 backwards compatibility (wsd: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span)|
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 11 Feb 2004 12:41:52 -0500
At 10:46 AM 2/11/2004, you wrote:
Ok I will plays devils advocate here...
Okay, I'll bite. :->
1. xslt that runs on the client needs to be portable, because there is
no control over the client environment - however, its likely to be IE
with msxml until the others catch up. Msxml doesn't support xslt 2.0,
and Ive heard there's no plans to support it, so the backwards
compatibility issues wont apply here.
This is arguing at the wrong level: you can't assume the current facts on
the ground will stay that way. Maybe "MSXML doesn't support XSLT 2.0 ...
and there are no plans to support it" -- but it would be regrettable if the
development of the standard turned this statement into a self-fulfilling
prophecy. What if MS had a change of heart? (Okay I'll go sleep it off.)
What if a yet-unknown developer is almost ready to announce some new
XSLT-client killer app? (She could be reading this list even now.)
Development of a standard has to be not only for this world, but also for
the possible worlds in which we'd like to live....
2. xslt that runs on the server / within an app doesn't need to be
portable, as there is control over the target environment. In this
situation a 10x improvement in performace is definitely preferred over
portability. Should the need arise to change processors, it does take
that much work to alter the processor specific stuff.
I think you're over-generalizing, and dismissing without consideration the
various reasons why portability is valued. Various *different* reasons.
For example, the services that my company provides include
vendor-independent training and design work. This is very valuable to our
customers because it means they can move forward on development without
locking into platforms and applications: this saves them both money and
grief. (Sometimes they choose to lock in later when their application is
more mature. Sometimes vendor-independence is actually of long-term value
to them as well, and they work to preserve it.)
I dare say DaveP and David C have different reasons why portability is
valuable even on the server. The *variety* as well as the legitimacy of
these reasons, and their variation in applicability to one or another
real-world situation (public sector, academic, shoestring budget, what have
you), is what confounds your assertion that it doesn't matter much. Doesn't
matter much for you is a far cry from doesn't matter much for the marketplace.
3. If your xslt is freely distributed, and the processor it runs on is
freely distributed, wheres the problem! Its all free, and it runs 10x
as fast :)
I think what you're missing is that portability is a different *kind* of
requirement from functionality and performance: it works on a different
level. While functionality and performance address getting the job done
today, in today's scenario, portability addresses getting the job done at
some other point in some scenario not mine, whether it be in the future or
already in some galaxy far, far away.
The roots of XML are in technologies that are designed (in part) to support
data that has to be more long-lived than the systems that process it.
Standard processing methodologies such as XSL raise this to another level:
not only can data, but now even much of a data set's concrete processing
semantics, can be expressed in a technology-independent way. We have only
begun to reap the rewards of this (although I bet readers of this list
could already tell war stories): why should we give it up?
You can't exactly plan for the "unknown unknown", as NASA engineers call
it, but you don't have to plan as if it will never exist. Fortunately for
us, the XSL WG seems to understand this all very well.
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
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
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list