Re: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span

Subject: Re: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 18 Feb 2004 14:00:47 -0500
David C,

At 11:15 AM 2/18/2004, you wrote (to David T):
I will :-). I don't think my reasoning will affect XSLT 2.0. But if there is
a theoretical chance to get XSLT 1.5, which is smaller than XSLT 1.0 with
extensions and cleaner than XSLT 1.0 without, then I would vote for it.

I think XSLT2 is actually rather good, or at least would have been good
if it wasn't tied to XPath2 which is still an unmitigated disaster as far
as I can see. I fear that the reliance of XSLT 2 on Xpath 2 will mean
that the majority of XSLT implementations will never switch (or not
switch in the forseeable future, which is the same thing) and as you
indicate will lead to divergent projects that try to cherry pick the
good bits out of the mess. While I am sure that many of these languages
will have excellent features, I fear that the notion of a standard
language will be gone. As I said on a recent thread (or was it this one)
I care more about interoperability than I do about efficiency (usually)
so I find this whole situation very worrying.

I agree with you on this. And it's generally known that many of us humble users, even without presuming to be experts in language design, have the same worries.

Well, except I might suggest that the unmitigated disaster promised by XPath 2 is being mitigated, at least to an extent, by the work of Jeni and others who have been trying their darnedest to explain it all to us.[1] Not that this makes the problem go away -- its root still seems to be the universal buy-in to the idea that XPath and XQuery should be unified, something which sounded like a good idea at the time but which, in the event, appears to shift the balance of the entire architecture assumed by XSL. A system that rewards -- even expects -- the full-blown Schema infrastructure, meaning a PSVI, datatyping ... the kind of thing that assumes that the source should be pre-compiled in some fashion ... is a far cry from a system that takes standalone source documents as discrete input at runtime (as for example on a client on the web, or in a document production system). But when we agreed that it would appear sensible to unify XPath with XQuery, we made the mistake of thinking that that meant XQuery would have the virtues of XPath, not that XPath itself would become incompatible with the lean-and-mean, loosely coupled infrastructure that has proven so effective for XSLT 1.0 (and for other XML technologies outside the Schema orbit).

The designers have urged that we can still do it the lightweight way if we want; but XPath 2 does seem to be rather a bear in such a circumstance, doesn't it?

Yesterday Mike wrote:
One of the aims behind the design that we adopted is that you should be
able to mix 1.0 and 2.0 code. We felt that this was necessary to make
transition as painless as possible.

While this aim is evidently well-intentioned, maybe it's part of the reason why we're now looking at such an infernal brew. The assumption that mixing 1.0 and 2.0 code will make the transition less painful would seem to be well-founded if 2.0 were simply 1.0-with-enhancements. But it's not, and its data model is so different that it may prove that being able to mix the code makes it more confusing and painful to make the transition, not less so.

As you recall, we were told nearly two years ago that the XQuery/XPath unification was a done deal, impossible to re-examine, water under the bridge. (I traded e-mails with one WG member when this issue came up in June 2002; while I felt at the time that I was able to budge him from the settled position that XSLT needed strong datatyping -- arguing that actually XSLT and XQuery would complement each other better if XSLT was allowed to be XSLT -- this apparently didn't do anything more than anyone else's fretting, here or elsewhere, to command the tides.) It's an odd sort of a "meta" world, isn't it, where Cassandra's cry is "don't let it become a self-fulfilling prophecy!" -- but Cassandra is never listened to, odd world or even.

Best-case scenario: XSLT 2.0 isn't all that bad. We can run stylesheets without having to buy IDEs for the half-baked schemas they generate, we can learn the arcana and gotchas of the datatyping, and just suffer with these things the way any developer suffers when using a mallet for a hammer. Worst-case scenario: it turns out this all-in-one supertool is not at all suited for banging nails, we never get stable and reliable implementations apart from Saxon, and we see the divergence and cherry-picking that you warn of, less of a common platform and less of the kind of thing that might be built on it. If it happens like this, those of us whose work is in facilitating the learning and adoption of openly-specified technologies in these areas will really have our work cut out for us.

A "third way" -- an XSLT 1.5 that has support for grouping and xsl:document, but not for doubles or dates (import a template library or use extensions to handle your dates!) -- would be marvelous, but it seems awfully unlikely doesn't it?

Still it doesn't seem to worry the person mentioned below, so it's
presumably not that important......


I'm glad that you at least have your priorities straight. I wonder what he'll be worrying about in thirty years.


[1] See Jeni's 2003 Extreme paper at

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