xsl-list
[Top] [All Lists]

Re: Re: How to output open/close tags independently?

2002-12-30 17:09:32
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(_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