Subject: Re: [xsl] RE: syntax sugar for call-template From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx> Date: Fri, 16 Feb 2001 22:52:42 -0700 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] RE: syntax sugar for call, Jeni Tennison | Thread | Re: [xsl] RE: syntax sugar for call, Clark C. Evans |
Re: [xsl] Rescuing XSLT from Niche , Jacobs,David B. | Date | Re: [xsl] Rescuing XSLT from Niche , Uche Ogbuji |
Month |