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(_at_)mulberrytech(_dot_)com
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
======================================================================