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: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)


> I've given a bit of thought to exsl:return and I see there
> are two distinct, and perhaps seperable requirements:
>  
>   (a) to exit a exsl:function 'early
>   (b) to allow the return of a node-set
> 
> Trying to keep them seperate, I came up with:
> 
> 1.  For this discussion, assume that a function always 
>     returns a node-set, aka list.  Call this growable 
>     list the result-set.
> 
> 2.  For normal template-style items, such as xsl:element,
>     xsl:value-of, xsl:text, let the corresponding result-fragment
>     be created; and then convert the result-fragment into a 
>     tempoary node-set, and append the node-set to the result-set.
> 
> 3.  Create a new tag, <xsl:append select="xpath" /> which will:
> 
>     (a) if the xpath type is a node-set, then it appends each
>         element of the node set onto the result-set.
> 
>     (b) otherwise, a text node is appended with the string-value
>         of the path expression.

I don't think this is necessary with an exsl:node-set().

> 4.  If execution must return 'early, then a new tag, <xsl:return /> 
>     can be used to return the result-set constructed.

Hmm.  Doesn't seem necessary in a declarative system, ecept perhaps as a 
performance hint (a la Prolog's "cut").

That's one reason I prefer "exsl:result" to "exsl:return".  It makes it easier 
not to confuse a declarative model with a procedural one.

> 5.  If given a select statement, like <xsl:return select="xpath" />,
>     then the xpath expression selected will be returned instead
>     of the result-set being constructed.

I can't think of any situations that the above system would enable that are 
not conveniently covered by the emerging shape of exsl:result.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 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]