[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Hi Julian,
At 03:00 AM 3/24/2004, you wrote:
That's cool.
The trouble is most likely in the assumption that the way to do it is to set a value and then change it later ... the XSL Way would probably be to use a particular value already set on a node in your source, falling back on another value if the source has no such value to use. More complex dependencies can also be modeled.
But it's difficult to show how this would be without more information about the particulars. And even in pure XSLT, when the dependencies get really complex one sometimes finds the easiest way is to pass over the data more than once (whether by pipelining transforms or by using the widely-available node-set() extension to process result trees) -- which is in effect what you're doing even if not using XSLT for the first-step transform.
So your solution may well be where you would get to in any case. Please don't take my remarks in the spirit of "you should be doing this", since I'm quite satisfied you are working out a strong approach. Rather, I mean only to caution you not to judge XSLT based solely on its lack of features you expect to have, when it has other features that can accomplish the same ends. One of these is the ability to inspect the source tree really easily: XPath gives you, in effect, "random access" to the source document, so for the most part you don't have to program the processor to go hunting for things; you just ask for them. Another of these is the ability not just to use if/then conditionals, but to select and/or match nodes conditionally as well.
Re: [xsl] Variables and Values
Subject: Re: [xsl] Variables and Values From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Wed, 24 Mar 2004 15:22:32 -0500 |
Hi Julian,
At 03:00 AM 3/24/2004, you wrote:
In hind sight it is actually more logical to preprocess the data. The application used to contain the code to collect the data via interactive questionnaires, process it and then do the merge - it makes more sense to stick the processing in with the data collection.
That's cool.
> Stretch your brain to accommodate the
> kind of technique that Andreas suggested, for example, and you find soon
> enough that XSLT provides alternatives to the techniques you know, that may
> require a little getting used to, but that are extremely powerful,
> flexible, and simple to use once you get the hang of it all.
I can see what Andreas is doing, however it doesn't provide a total solution.
The sort of logic I am trying to replace is as follows:
IF NOT ANSWERED( PWQ ) SET PWQ TO FALSE END IF IF Rerun = FALSE SET RBSchild TO FALSE END IF IF Draft = TRUE SET Plan1 TO TRUE END IF IF TestDetyn = TRUE SET Plan7 TO FALSE ELSE IF TestDetyn = FALSE SET Plan7 TO TRUE END IF IF Mirroryn = FALSE SET Singleyn TO TRUE END IF
OK, the original logic (this is only a fraction of it) needs to be sorted
though because there are a number of diuplicates, however I will still need to
be able to set a value and then change it later based on some other condition.
I would be interested to know if there is an XSL way to do that.
The trouble is most likely in the assumption that the way to do it is to set a value and then change it later ... the XSL Way would probably be to use a particular value already set on a node in your source, falling back on another value if the source has no such value to use. More complex dependencies can also be modeled.
But it's difficult to show how this would be without more information about the particulars. And even in pure XSLT, when the dependencies get really complex one sometimes finds the easiest way is to pass over the data more than once (whether by pipelining transforms or by using the widely-available node-set() extension to process result trees) -- which is in effect what you're doing even if not using XSLT for the first-step transform.
So your solution may well be where you would get to in any case. Please don't take my remarks in the spirit of "you should be doing this", since I'm quite satisfied you are working out a strong approach. Rather, I mean only to caution you not to judge XSLT based solely on its lack of features you expect to have, when it has other features that can accomplish the same ends. One of these is the ability to inspect the source tree really easily: XPath gives you, in effect, "random access" to the source document, so for the most part you don't have to program the processor to go hunting for things; you just ask for them. Another of these is the ability not just to use if/then conditionals, but to select and/or match nodes conditionally as well.
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Variables and Values, Julian Voelcker | Thread | Re: [xsl] Variables and Values, Julian Voelcker |
RE: [xsl] xsl:key use attribute usi, Xiaocun Xu | Date | [xsl] performance and the xsl:for-e, Gruenewald, Terry |
Month |