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
Hi Andrew,

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. 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:

Current Thread