|
Re: Normalize / Simplify HTML-Tables with row-span / col-span
2004-02-18 12:00:47
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......
--
http://www.dcarlisle.demon.co.uk/matthew
I'm glad that you at least have your priorities straight. I wonder what
he'll be worrying about in thirty years.
Cheers,
Wendell
[1] See Jeni's 2003 Extreme paper at
http://www.mulberrytech.com/Extreme/Proceedings/html/2003/Tennison01/EML2003Tennison01.html
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
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
|
|