Re: [xsl] Variables and HTML

Subject: Re: [xsl] Variables and HTML
From: "Nathan Young" <natyoung@xxxxxxxxx>
Date: Mon, 14 Mar 2005 15:26:42 -0800

On Fri, 11 Mar 2005 19:19:16 -0500, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> 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.

To do otherwise I would either need to build the whole system myself or hold a sufficiently large bludgeon over a bunch of technical and authoring groups, neither of which is possible I'm afraid. But I do champion the benefits whenever I get a soapbox!!

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.

Before css we used to get rid of the extra whitespace caused by the end form tag by sandwiching it between table rows. Most of these hacks have fallen by the wayside as long as you don't have to support older browsers, but some persist. Customizing the serializer isn't a possibility for our case... I might need some more convincing before I agreed it was really an appropriate solution even in the abstract.

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.

I have a template that splits a three tiered listing (headers subheaders and list items) into two columns. The break point is chosen as follows (first condition met is used):
- if there are first level headers at the midpoint or within 7 items after
the midpoint, break at the first one
- if there are 1st level headers within 3 items before the midpoint use the
last of those.
- repeat the above two for second level headers.
- if nothing else, break right on the midpoint.

The breakpoint is calculated and the ID of that node is placed in a variable in global scope.

A table is built for the list to go in and the first column is started. When the breakpoint node is rendered, a named template is called which ends the first column and starts the second (with logic for continuation headings).

I'd love to have a better solution for this, so let me know if you have any thoughts!

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 admit that the idea that XSL has identical requirement for output as it does for input is a new though very elegant and compelling idea for me. It does seem to fly in the face of a lot of marketing material crowing that XSL isn't just for XML output, it can do csv, acrobat, etc.


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. 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

Current Thread