Subject: Re: [xsl] Variables and HTML|
From: "Nathan Young" <natyoung@xxxxxxxxx>
Date: Mon, 14 Mar 2005 15:26:42 -0800
We use d-o-e extensively for the use case Michael describes, namely we
format the last stage of output from a Gordian publishing system. The XML
instance that gets built for us quite often contains text nodes that
consist of escaped HTML blobs.
I agree with Mike that this is a thinkable use case, though as a purist I'd always like to see any incoming HTML tidied into proper XML syntax as early as possible, so I could get control of it. But I can (barely :-) imagine how other options might sometimes make sense.
We also use it for two other less common cases. One is where because of some browser vagary we want to generate and output HTML that's not valid XHTML. We can't embed it in the XSL because it would cause the XSL file to be ill-formed. Neither can we use xsl:element to construct it.
*In theory*, an HTML output method with a conformant serializer should take care of this kind of thing, and a purist approach to dealing with related problems (maybe this is really weird non-standard HTML or something) would be to customize a serializer. In practice, d-o-e might be much more thinkable, and if it were used with sufficient care (in the archive you can threads in which we discuss ways of managing d-o-e dependencies so they don't infect the rest of your code), even a purist might have to concede its practicality, I suppose.
The last use case is where we do (or could) have a well formed output doc
but because of the way it is constructed the XSL becomes badly formed.
Most obviously this occurs where the start and end tag are generated in
different xsl:templates. I've had good luck getting rid of most of these
so I don't have an example on hand but I'm not quite willing to rule it
out as logically impossible.
I've never seen one of these that couldn't be coded the "proper" way, usually by placing the wrapper element in a template matching an element higher in the tree (usually a parent) than the elements that are to get the open/close pair. I'd like to see one that couldn't be fixed: it would be a very instructive counter-example.
That having been said, I concur that tag-writing may be a reasonable way to think about doing certain kinds of work that prove (very) difficult to approach otherwise, such as dealing with "overlap" or the various ways XML fakes overlap. But it's not really XSLT, even if you use an XSLT engine + serializer to implement it, and when I think about this it's always in the part of my brain behind the door marked "Heresy: Enter at Your Own Risk".
I'll let others comment on the implications of XSLT 2.0 for the three cases described.
Thanks for posting them!
====================================================================== 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 ======================================================================
Nathan Young A: ncy1717 E: natyoung@xxxxxxxxx