I think that using xsl:for-each is the natural way to do this.
I toyed at one time with adding a construct such as
<xsl:with select="....">
that changes the context node without any iteration semantics, but it's
functionality that for-each already provides so it just seemed like
unnecessary baggage. I think this applies even more to an extension element
which needs to be separately implemented for each processor.
With XQuery I sometimes use the construct:
declare function cc($in as node()) {
$in/(
.... function body with $in as context node ....
)}
This isn't possible in XSLT of course because we don't have full
composability. I'm not all that sure how good an idea it is anyway.
Michael Kay
http://www.saxonica.com/
-----Original Message-----
From: Nils Kaiser [mailto:NilsKaiser(_at_)gmx(_dot_)de]
Sent: 16 March 2006 10:37
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: [xsl] Porting own template language to xslt
Hi,
we have been developing a template system similar to xslt
some time ago
and want to port it to xsl to enhance functionality and
become standard
compatible. As the language is quite similar to xslt it's
should not be
that hard. The only problem I have is the following:
the language we developed has a <region> element where you
can specify
an xpath. It simply changes the current node while staying in
the same
template. for example (I converted the other elements to xsl already)
<template match="/html">
<xsl:value-of "head/title"/>
<region select="body//div[(_at_)class='content']">
<xsl:value-of "h1"/>
</region>
</template>
What is the best way to express a construct like this in xslt? Well I
could use a xsl:for-each which matches just the first result,
but that
looks quite ugly... any suggestions?
I also thought about coding an extension element to be able
to use our
region element. But I am not sure what drawbacks I have to face
regarding compability to different processors. I can live
with the need
of writing more than one extension to support the element,
but are there
any processors that don't support extension elements at all?
(At least
in java world?)
Any ideas?
Thx,
Nils Kaiser
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--