This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: RE: syntax sugar for call-template
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] RE: syntax sugar for call-template
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Fri, 16 Feb 2001 22:52:42 -0700
- cc: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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@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