At 2011-09-29 13:49 -0700, Mark wrote:
(1) Please think of the <Value> attributes as though 'kc-value' were
equivalent to 'dollars' and 'h-value' to 'cents' (the l-value
mentioned earlier is like those US stamps issued just before a rate
change that are expressed as a letter value). <Value> attributes can
only appear [ignoring the specific instance values given here] in
the following combination:
<Value kc-value="1"> think of this as $1.
<Value kc-value="1" h-value="50"> Think of this as $1.50
<Value kc-value="0" h-value="50"> Think of this as $0.50
<Value kc-value="0" l-value="A" Think of this as one of those
strange rate-change postage stamps that have a letter value of 'A'.
Note that kc-value is required, the other two, h-value and l-value,
are both optional and are mutually exclusive. When l-value is
present, kc-value must be set to the value '0'.
I'll assume you already have pre-validation for that.
(2) These <Value> elements would produce this XHTML for the
particular target XHTML page:
<a href="../aval/0-50.htm">40h</a> <!-- think of 40cents -->
This is why I was ineptly trying to change my strings back into nodes.
Please don't use words like "ineptly" ... many on this list are also
trying to learn these principles. You just had a perspective that
wasn't taking advantage of the inherent XML facilities in XSLT. XSLT
was designed *for* XML, not just a tack-on of a bunch of subroutines
as is true for non-XML languages.
(3) I need to modify your 'reports' function to accommodate all four
possibilities, but do not know enough about XPath to do it. May I
bother you one more time to show me how?
This is untested, but it is a simple walk through the iterations ...
note in XSLT the <xsl:choose> is not a switch (requiring unique
cases), rather it is an "if-elseif-elseif-elseif-else" construct, so
the first one that is true wins:
<!--ignore kc-value and h-value-->
<!--both in play-->
As an aside, the stylesheet transforms the XML into an XHTML page
for every <Stamp> element, and to an additional page for each of the
different <Formats> elements (there are five optional possibilities).
Remember that in XSLT 2 you can nest <xsl:result-document>
constructs, so that while you are building your <Stamp> result, you
can detour and write out a complete <Formats> result and then get
back to where you were building your <Stamp> result. You don't have
to finish the outer one to write the inner one, but you do have to
finish the inner one before continuing the outer one.
It is *extremely* easy for me to identify which pages to generate
when I am in the context of a <Stamp> element that has certain
characteristics (and these characteristics change). I suspect that
someone with your sophistication could do it from the context of the
<Set> element, but it escapes me how to do it that way. This is why
I keep rewriting the suggestions I have received to operate from
within the context of a <Stamp> element rather than from within the
context of the enclosing <Set> element. Dumb, I know, but I already
know how to do it.
Again, please don't use the word "dumb". Without knowing your
requirements intimately I think your intuition is sound: you say you
need to act on the (I'm assuming unique) <Stamp> element, so act on
it in my report function. If you need to act on *every* <Formats> in
then do it outside of the handling of <Stamp>. If you only act on
the ones in <Stamp>, then do so when handling <Stamp>. You won't be
interrupting your <Stamp> output if you completely write a <Formats> result.
I have overrun my daily (weekly!) contribution time for vounteering
so will leave it in what I'm sure are your capable hands if you pause
to look at the big picture of what you are trying to do.
. . . . . . . . . . . Ken
Contact us for world-wide XML consulting and instructor-led training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>