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[(_at_)name='a']/item[(_at_)name='b']/item[(_at_)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:
[(_at_)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