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