Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Variables and HTML
 A couple of comments from a notorious purist: At 06:47 PM 3/11/2005, Nathan wrote: 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! Cheers, Wendell
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
