This is the mail archive of the xsl-list@mulberrytech.com mailing list .

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Evaluate a string to a node set?

Jeni, (& Mike)

Thanks for the info. The 'simplified syntax' approach looks good. Now all I
need to do is get it to work with my processor!

The extra functionality I'm looking for is related to personalisation and
portals. The idea is to let the user pick the layout of the pages they view
beyond limits of a typical portal implementation. The user can create custom
layouts (which translates to nested tables) and then pick *any* data to
appear in that table cell. Basically I'm trying to create a portal based on
XSLT.

Your comments are food for thought and I guess I need to revisit the
multiple stylesheet approach.

My main concern is that our designers should be concerned only with visual
layout and our content providers only with content. I don't particularly
want either of them dealing with the _glue_ which is how I've come to see
the stylesheet in this application.

Thanks to Mike Kay for pointing out that saxon:evaluate() is what I need. I
shall try this out, but I'm now worried that I'm barking up the wrong tree
w.r.t my overall approach.

Thanks for your insights and help.


Andy.



-----Original Message-----
From: Jeni Tennison [mailto:jeni@friday.u-net.com]
Sent: Thursday, August 03, 2000 6:44 PM
To: Hitchman, Andrew
Cc: xsl-list@mulberrytech.com
Subject: RE: Evaluate a string to a node set?


Andy,

>I've already tried this approach, but enclosing the presentation HTML
within
>the XSL stylesheet (or even including it as a template) causes problems
with
>HTML editors (Dreamweaver2 blows-up).

I think that Chris was trying to get at using the 'simplified syntax' for
stylesheets with only a single template for the root node.  If your HTML
editors were to produce a file like:

---- team.html ----
<html xsl:version="1.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
  <title>View Team <xsl:value-of select="/team/name"/></title>
</head>
<body>
  <h1>Team <xsl:value-of select="/team/name"/></h1>
  <xsl:value-of select="/team/notes"/>
  <h2>Schumacher</h2>
  <p>DOB: <xsl:value-of
select="/team/driver[name='Schumacher']/date-of-birth" /></p>
</body>
</html>
----

Then using team.html *as the stylesheet* with team.xml as the source
produces:

---- out.html ----
<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
  <title>View Team Ferrari</title>
</head>
<body>
  <h1>Team Ferrari</h1>
  Bla-bla-bla...
  <h2>Schumacher</h2>
  <p>DOB: 1969-01-03</p>
</body>
</html>
----

Maybe this is what you've already tried; if so, what is it that
Dreamweaver2 blows up on?

Another solution is to preprocess the HTML files that your HTML designers
are generating into XSLT stylesheets that you can then use on your XML data
to get the final HTML document.  A preprocessing stylesheet would look
something like:

---- preprocess.xsl ----
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:oxsl="http://www.w3.org/1999/XSL/TransformAlias"
                xmlns:html="http://www.w3.org/TR/xhtml1/strict"
                exclude-result-prefixes="html">

<xsl:namespace-alias stylesheet-prefix="oxsl" result-prefix="xsl"/>

<xsl:template match="/">
  <oxsl:stylesheet version="1.0">
    <oxsl:template match="/">
      <xsl:apply-templates />
    </oxsl:template>
  </oxsl:stylesheet>
</xsl:template>

<xsl:template match="*">
  <xsl:copy>
    <xsl:copy-of select="@*" />
    <xsl:apply-templates />
  </xsl:copy>
</xsl:template>

<xsl:template match="html:xdata">
  <oxsl:value-of select="{@select}" />
</xsl:template>

</xsl:stylesheet>
----

This has the advantage that you don't have to train the HTML designers to
insert xsl:value-of elements and all the namespace and version information
that you do if you're using their work directly as a stylesheet, and that
you don't have to change the HTML templates they've already generated.

An additional advantage of this technique is that you could alter the
xdata-matching template slightly to *apply templates* rather than include
the value:

<xsl:template match="html:xdata">
  <oxsl:value-of select="{@select}" />
</xsl:template>

and then include other stylesheets that know how to format specific pieces
of your data in specific ways by adding an oxsl:include in the generated
stylesheet:

<xsl:template match="/">
  <oxsl:stylesheet version="1.0">
    <oxsl:include href="formatting.xsl" />
    <oxsl:template match="/">
      <xsl:apply-templates />
    </oxsl:template>
  </oxsl:stylesheet>
</xsl:template>

The downside, of course, is that preprocessing is a pain.

>Moreover it doesn't fit with my overall strategy of separating
presentation,
>data and the logic which combines them.
>
>One of my goals is the ability to present the same XML with the same
>stylesheet in different HTML pages (i.e. different layout, same data). The
>idea is to create HTML fragments from the XML to slice into a master HTML
>document.

I've always thought of the source document as the data, the stylesheet as
the presentation, and the logic that combines them being that which is
documented in the XSLT Recommendation and implemented in the XSLT
Processor.  XSLT templates are all about generating HTML fragments from XML
to place into a HTML document.  Perhaps you can explain exactly what extra
functionality you're aiming for?

I hope this helps, anyway,

Jeni

Dr Jeni Tennison
Epistemics Ltd * Strelley Hall * Nottingham * NG8 6PE
tel: 0115 906 1301 * fax: 0115 906 1304 * email:
jeni.tennison@epistemics.co.uk


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


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]