Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xsl] iterate through nodes and determine output by node type

From: "Scott Trenda" <Scott.Trenda@-------->
To:
Date: 10/1/2007 7:19:00 PM
Awesome. I'll be remembering this, thanks. ^_^

While we're on the subject, has anyone seen a stylesheet that
(accurately) replicates the behavior of <xsl:output method="html"/>
under <xsl:output method="text"/>? I'm not a masochist, I swear, but I
do have a legitimate reason for it.


The company I work for uses a proprietary preprocessor that's similar to
ColdFusion. It smells like XML - that is, its flow control is based on
statements (elements) and arguments (attributes) - but it's got several
quirks that prevent it from acting like XML - that is, there's no way an
XSLT processor would output some of the tags without blotching it up as
to where it's unusable by the preprocessor. Nevertheless, in our main
display-generation engine, we use XSLT extensively, converting a display
configuration into a full HTML display, transforming a small piece at a
time. (So it's essentially a primitive pipeline, but don't tell them
that. ~_^)

In a handful of the main stylesheets at the end of the transformation
chain, the output method is "text", but its result document is the
template to generate our datatables, consisting of a mix of HTML and
preprocessor tags. And, as expected with output="text", it's an ugly sea
of <![CDATA[]]> and <xsl:text>&#xA;&#x9;&lt;tagName </xsl:text>, and
something as simple as adding an attribute turns into several lines of
workarounds and eggshell-stepping to produce bug-free output.

And so, my idea to clean up the mess was to create a small XML wrapper
syntax for the preprocessor language, which could be converted to
accurate, pretty-printed script through a generic translation
stylesheet. However, since HTML will be interspersed within these
preprocessor elements, but will exist as XML until then, I'll need to
fall back on an imported HTML-to-text stylesheet to handle any HTML
elements I might not see along the way.


I've laid down some basics for that stylesheet, but got discouraged
after building the list of HTML elements and attributes it needs to
check when converting. If anyone has seen a stylesheet for this purpose
perfected within some sort of standard library (I've checked xsltsl
already), I'd be forever grateful if they'd point me at it. ^_^

Oh, and it has to work within MSXML and XSLT 1.0. Thanks!


~ Scott


-----Original Message-----
From: Nick Fitzsimons [mailto:nick@xxxxxxxxxxxxxx]
Sent: Monday, October 01, 2007 1:57 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] iterate through nodes and determine output by node
type

On 1 Oct 2007, at 17:43, Scott Trenda wrote:

> For reference, the list of HTML elements is here:
> http://www.w3.org/TR/html401/index/elements.html
>
> Not sure where you'll find whether each one is block or inline, but
> I'd
> imagine it'd be in the CSS recommendation.

Actually it's specified in the HTML DTD, right around:
<http://www.w3.org/TR/html401/sgml/dtd.html#block>

The easiest way to look at it is that, if it's not listed under
"block" (including the three subgroups %heading, %list and %
preformatted), then it's inline, as there are slightly more nested
subgroups of elements listed under inline, and going through the
whole DTD to find the definition of each in terms of actual element
names is a pain :-)

Regards,

Nick.
--
Nick Fitzimons
http://www.nickfitz.co.uk/


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent