Ed,
At 05:44 PM 12/30/2002, you wrote:
Not that I'm picking on you specifically Wendell, but your reply was the
most blatantly representative of a class of responses of a particularly
XSL purist/snobbish nature which I find extremely objectionable. There
was a reply from a Mitch Amiano which actually supplied a suggested
approach which "appeared" entirely reasonable, so tried it out. I've
included the core XSL for both approaches below: the "bad" code which
had the 'disable-output-escaping' clause and the "good" code which
generated the Page element directly.
I'm sorry you found the tone of my post objectionable. If you care to write
me privately, maybe the reason(s) you found it to be so might be isolated
and addressed (and I could do better in future).
I don't want to rehash the issues here again, especially given that you
don't like my tone. But it may be worth restating a couple of points that
may have been too deeply buried:
(1) My (and I believe others') objections to d-o-e-based solutions have
nothing to do with their performance. (On the contrary, you are likely to
find that using XSLT to write tags can be a *very fast* way to solve
certain problems. So is Perl, with which this approach has more in common
than it does with "pure" XSLT.)
(2) The reason d-o-e is "not recommended" has to do with something much
more subtle than whether it "works" or not. The problem with it is that
it's a feature that is (a) not mandated for compliance (i.e. not all
processors have it, so it's not portable), and (b) dependent on a
processing stage (serialization directly after the transform) which may or
may not happen. This means that it sometimes works (and works well, if
you're careful), and sometimes doesn't work at all. (This has all been said
on the list before.)
My recommendation has been *if* you understand the dependency introduced by
d-o-e, and *if* you are sure that's fine for your case, then go ahead and
use it. But if you don't understand it, or if you can't be quite certain
the dependency will never be a problem -- stay away from it.
Unfortunately, we also have a higher-level problem in that this advice has
to be given repeatedly on this list, and in all those repetitions I and
some others may come off as "purist" and even "snobbish", taking such
trouble to warn new users about something so arcane (and evidently so
useful). Yet it is scary to think of the alternative -- how the list would
howl if we recommended d-o-e, and then had to deal with a permathread of
"you recommended d-o-e and now my stylesheet won't work in X!".
Following are my performance
numbers on a test input file
...
The "good" approach took hours; the "bad" approach took minutes. For
those that will care, the test environment was a Sun Solaris platform
using the interim release of the Xalan C++ 1.4 XSLT processor.
I'm not surprised at these numbers. The kinds of grouping-and-splitting
operations for which d-o-e is commonly resorted to are typically very
processor intensive.
As to whether the speed makes the "bad" solution better than the "good" one
-- I can't say that ... it depends on whether this trade-off (performance
vs. full conformance to XSLT) is acceptable to you. There's nothing
inherently wrong with you or your XSLT if it is ... it's just that you've
taken a subtle step away from full portability. You should be aware of
that, just as you should be aware of dependencies introduced by extension
functions (and for the same reasons). Nor can I say off hand whether this
should be a big deal to you, or not. To some developers it's no big deal at
all; to others it can break a project. Or: the *true* answer to the
question "Is it really a bad idea for me to use d-o-e?" is "It depends; but
if you can't tell when it's a bad idea, then it probably is".
I'm just curious, do those of you with this hard-line "purist" attitude
actually use XSL to do real work or are you mostly academics and tool
developers/vendors?
I can't speak for others, but as for me -- I suppose some would say the
work I do is "real", others maybe not. (But why the sneer against
academics? isn't the work they do "real" enough for you? in what respect
does it fail the reality test? Off list, please.) It does involve, FWIW,
writing and running a good amount of real XSLT over data both "real" and
"fake", both for clients and for our internal use here at Mulberry. (You
can take a peek at http://www.mulberrytech.com to decide whether you think
we do real work.)
I understand staying true to a paradigm up to a
point, but sooner or later "the rubber has to hit the road".
Um, has anyone said anything to suggest otherwise? Rather, I think our
concern has been to caution what may happen when you hit the road wearing
those chains on your tires (which may be great for getting you out of that
icy hole), and the snow melts.
Cheers,
Wendell
======================================================================
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