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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format