RE: Porting own template language to xslt

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@xxxxxx] 
> Sent: 16 March 2006 10:37
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:  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[@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