Re: [xsl] Are long XPath statements inherently bad?

Subject: Re: [xsl] Are long XPath statements inherently bad?
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Tue, 26 Oct 2004 21:14:16 -0700
As far as logic is concerned if you can simplify your XML result set with XPath instead of sending the entire tree through a series of xsl conditional logic elements your probably better off. Of course without seeing your XML and what you ultimately want as output its tough to say one way or the other if there is a simpler way to accomplish this.

I am kind of wondering what this is:

[( @yearspecific, . ) != 1

theres no preceding function name and its not an equation so I'm not quite sure what you are trying to create to then compare its value and I doubt your processor does either.

Depending on the processor you are using you may be able to take advantage of the EXSLT date extensions. See This is one of Jeni Tennisons projects so you can feel confident that its likely to solve a good portion of the issues that either can't be solved with XSLT 1.0 or are so verbose (read ugly and unnatural) and processor intensive they needed another way. Saxon (and inherently Saxon.NET) support EXSLT but if your going to move that direction you might as well begin developing in XSLT 2.0 which has date processing built in. There are a few other processors that support EXSLT as well... the site has a listing of the functions and the processors that support each one.

With all of this said, you may very well be trying to create something that is much better served using a server side control with ASP.NET. If you are thinking of going this route anyway youre going to find yourself being much more productive using the calendar control that comes as part of the standard ASP.NET component library. With the data binding capabilities etc... its a much more robust solution and I would highly recommend it if you decide to go the .NET route. Coincidentally you can also develop and run ASP.NET (including the calendar control I believe) using Mono which gives such a solution a cross-platform appeal. See for more details.

Best of luck!


John wrote:

Sorry again, I am relatively new to XSL. I am trying to put together of events as a table by outputting a list of items in each cell by executing queries such as the following (this is actually simplified):

select="$newshome/item[@key='recurring']/item[@template='event'][( @yearspecific, . ) != 1 and substring( @date, 5, 4 ) = $moday ) or ( @yearspecific = 1 and substring( @date, 1, 8 ) = $date )] | $newshome/item[@key='recurring']/item[@key=$year]/item[@template='event'][( @yearspecific != 1 and substring( @date, 5, 4 ) = $moday ) or ( @yearspecific = 1 and substring( @date, 1, 8 ) = $date )]

Is it just my syntax/logic that's bad or is there some better way I could/should do this? The requirements for including events for a date are actually pretty complex - this is just one of a series of queries (which I would be happy to share!) to get events for a date. Are long XPath statements always bad, other than just the possible readability issue?

The calendar does have performance issues and I will probably rewrite it in .NET. Would you expect XSL extensions to be helpful here, or just use pure .NET (maybe an ASCX) or something I'm not thinking of?

I probably need to convert this to CSS positioning and I'm not sure if that would help with the problem or make it harder.

Thanks in advance,


Current Thread