Re: RE: syntax sugar for call-template

> Hi Uche,
> 
> > introspection is in short the ability to query an object for its
> > metadata. For example. An example of metadata of a named template
> > might be the parameters it expects. Metadata on a stylesheet might
> > be the templates it provides.
> 
> Can't you do this already through document('')?

Yes.  document('') does provide a measure of introspection.  It's actually a 
healthier approach than many generally procedural languages allow.  The data 
model of the instructions *is* the execution model.

> For example, to get a
> list of the named templates provided by a stylesheet, you can use:
> 
>   document('')/*/xsl:template[@name]
> 
> and to get the names of the parameters on a template named 'my:func',
> you can use:
> 
>   document('')/*/xsl:template[@name = 'my:func']/xsl:param/@name
> 
> and so on.
> 
> Having said that, this is really limited because it works on the
> stylesheet document node tree, not the extended logical structure that
> comes with it - you can't use this method to query into the *imported*
> and *included* templates (well, you can but it's quite a bit more
> complicated).

It's more complicated, but I think here you run right across what I have in 
mind.

To provide better introspection in XSLT, no grossly bolted-on API is needed, 
but rather a few convenience functions that package the abstractions more 
effectively.

For example, an aggregation of all templates, whether in the current 
stylesheet or in included ones.  With expressions as first-class objects 
(low-hanging fruit as far as I'm concerned), they can be parameterized not 
only with respect to their names, but also with respect to their match 
patterns.

> > Imagine being able to automatically assign items in a node-set to
> > the corresponding positional parameters in a template (with position
> > being determined by the document order of the with-param elements in
> > the template).
> 
> I think I know what you mean here - if the node set $list contains two
> elements, 'one' and 'two', then something like:
> 
>   my:func(expand($list))
> 
> will be equivalent to:
> 
>   my:func(one, two)
> 
> Right? I think that one problem with this is that node sets in XSLT
> aren't like arrays in normal programming languages - you can't fix
> what order things should be defined in.  Imagine that the nodes that
> you wanted to pass as arguments were attributes - you couldn't make
> sure that one particular attribute was passed as the first argument
> because you don't know what their document order is going to be.

The attribute monkeywrench, surely enough.  Of course it's no new problem.  
Right now if you have a node set full of attributes and pass it to name() or 
any such funcion, you have no idea exactly what you'll get.

Other than that, any pre-imposed ordering, such as document order, would 
lessen the value of the technique, so I guess there's not much for the idea.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +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