[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Are long XPath statements inherently bad?

Subject: Re: Are long XPath statements inherently bad?
From: John <john-xsl-list@xxxxxxxx>
Date: Thu, 28 Oct 2004 10:49:48 -0700
xpath conditional logic
M. David Peterson wrote:

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

Can you confirm my understanding of these terms - I thought the whole long crazy query was an XPath, but it sounds like you're saying things like element names and axes are XPath and predicates are conditional logic.


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 creating a monthly calendar by pulling events from a variety of places in my source XML. These crazy queries get the appropriate events for a date. Sorry I can't share the source XML, which I don't have much control over. Which leads to another question - if I have XML that can be accessed with queries such as /*/item[@name='a']/item[@name='b']/item[@name='c']/... where each item has a name attribute and child elements, would it be possible/easy/efficient/helpful to create an in-memory representation of this structure using the name attribute as the element name, so that I can construct XPath using the attribute names as element names instead of referencing them in the predicate (for instance, /*/a/b/c)?


I am kind of wondering what this is:

[( @yearspecific, . ) != 1

I am very sorry, this comes from my simplification of the XSL (I removed an extension function call but forgot to remove the parens and one of the params). It should have been simply:


[@yearspecific != 1

The logic is to look for events that do not have dates that vary by year (for instance, Christmas is always 25 December so this condition would be true for that event, but Thanksgiving varies so this condition would not be true for that event).

Depending on the processor you are using you may be able to take advantage of the EXSLT date extensions.

My environment is .NET, which I don't think has these extensions (maybe I can install them), and I don't think is leading towards XSLT 2. It's pretty easy to write XSL extensions in .NET for my date logic, but I am not sure what performance differential this would have vs. a .NET control not using XSLT.


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.

I agree, from a development perspective this is a lot easier. But from a presentation perspective I prefer the flexibility I have in my XSLT version. And since the source data is XML I was hoping for an easy XSL solution. I may put map some of the XML to a database to make things easier and faster. I will try some different things and try to see which has best performance/maintainability, but any inputs on these topics would be appreciated.


I really appreciate your detailed response, thanks again.

-John

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.