RE: embedding html tags in xsl?

> My concern is that once html tags are introduced into a
> style sheet, its flexibility has been compromised, and
> that xsl style sheet can only be used to output html.

Not exactly. The HTML is going to be in a template. There's nothing stopping
you from putting, say, WML in another template in the same stylesheet. Or
even in the same template (see example at end).

> From a design standpoint how can I not lock myself into
> writing an html specific stylesheet. My understanding is
> that an xsl style sheet should be generic enough to
> handle any output (simply change the xsl:output, right?)

Remember, what you put in the stylesheet is instructions for how to create a
result tree. Serialized (linear bytestream) output is something that may be
derived from that tree. Don't think of what you put in the stylesheet as
being one and the same with the literal output you expect to get.

xsl:output gives a hint to the XSL processor that you'd like it to serialize
the result tree, and that it should do so in such a way that a well-formed
XML document is produced (if method="xml", and then your output would likely
be XHTML), or an HTMLish document (i.e., not well-formed, but pretty close),
or as text with no markup. Try making a stylesheet that creates a result
tree with some HTML elements, and compare the output you get with
method="xml" vs method="html".

The 3 output methods allow for just about anything to be output - that is,
any XML-based language can be output by the xml method, the quirky HTML
variants can be output by the html method, and most anything else can be
handled by the text method. All you have to do is construct the result tree
apporpriately.

> Are we just not there yet? Perhaps some notion of a
> meta-tag that describes some xsl elements?
> Do I have to wait for total support for formatting
> objects before I can be this flexible?

Formatting objects are still print media oriented, hence the existence of a
FO-to-PDF tool. But there's nothing special about them, really -- I mean,
they are an XML representation of, well, objects for formatting. They're an
abstraction. They say things like "here's a box with margins and padding and
border and some stuff in it". Rather than wrapping your source data in HTML
elements, you can wrap them in FO elements. Then you can use the FO XML you
produce as input to another tool, perhaps as source data for another
stylesheet... and interpret them however you want. You can transform all
boxes with margins and padding and border into a single-cell HTML table, for
example. Unfortunately, the FO side of XSL isn't good for producing complex
web documents, at least not in the world of pre-XHTML browsers and the kinds
of things people like to do in their HTML documents.

So if you want, you can do something similar with your application. Wrap
your data in some generic intermediary objects that you can then
translate/interpret in a second pass (or by using/abusing xt:node-set). Or
do something like this:

some XML:

<doc>
  <target>html</target>
  <data>Hello World</data>
  <data>Good Morning</data>
</doc>

some XSL:

<xsl:variable name="target" select="/doc/target"/>
<xsl:template match="data">
  <xsl:choose>
    <xsl:when test="$target = 'html'">
      <p><xsl:value-of select="."/></p>
    </xsl:when>
    <xsl:when test="$target = 'nothtml'">
      <foo><xsl:value-of select="."/></foo>
    </xsl:when>
    <xsl:otherwise>
      <xsl:copy-of select="."/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list