At 12:52 PM 10/5/2009, you wrote:
unparsed-entity-uri(ancestor::ipb/figure/subfig/graphic[(_at_)boardno=$sht_num]/@boardno)
In this case I probably should have rearranged the when and
otherwise tests and matched the good value and let the otherwise
handled everything else. ultimately I also realized there was no
value in doing this elaborate matching as the result is the same as
the $sht_num.
Yes, exactly.
If $value is known to be 'x', then /path/to/node[(_at_)with=$value]/@with
is always either
* 'x' (a @with node exists, and it has value 'x' by virtue of the
'@with=$value' predicate on its parent in the path), or
* Nothing (no such node exists, has no value, coerced to '' when
cast as a string)
This is what I tried first, if no match I expected the empty string.
That is what the error from unparsed-entity-uri() lead me to believe
- the error message made me do it ;-)
That's effectively what you have with
"ancestor::ipb/figure/subfig/graphic[(_at_)boardno=$sht_num]/@boardno".
(I leave aside the possibility that there may be multiple such nodes.)
That might have been another error to eventually check for, but I
would think the XML parser (Arbortext Editor) would prevent that situation.
I think you have two questions:
1. What is unparsed-entity-uri($sht_num)?
I know what it is when there is a match. It was actually what the
value was when this was actually evaluated to create the $sht_num in
the original code is the question.
2. Is $sht_num referred to elsewhere in the document?
No this was just primarily to test this match to the graphic tag to
then find the boardno value which was "officially" the reference to
the entity definition.
The only think I can think of is the original coder thought there
might be a difference somehow. I know that there are situations where
there are multiple sheets of a given engineering drawing and I think
this is where the attribute/variable name came from. This I think
lead to the idea that somehow there was a sheet within the graphic
that would be separate from the file name. Some of the graphics were
PDF files that have multiple sheets/pages, but have a single file
name/entity definition. Could be this was an early design that
changed as well that didn't get cleaned up.
... and the code you are refactoring has conflated these.
This might sometimes be useful, if for example you are only
interested in (1) if (2) is true. That is,
unparsed-entity-uri(ancestor::ipb/figure/subfig/graphic[(_at_)boardno=$sht_num]/@boardno)
will return a URI if (and only if) $sht_num appears as a @boardno on
an ancestor::ipb/figure/subfig/graphic, and is also declared as an
unparsed entity (with a URI not ''); otherwise it will be ''.
So why did my when clause testing against the '' (empty string) not
fire? That was my first impulse.
So I had a value in $sht_num and it didn't match any graphic
element's @boardno. We had differences in the format of the values
that the XML parser couldn't check. We inherited this legacy code and
documents and have been trying to reverse engineer the logic that
went into the original creation of the content as well as stylesheets.
But you still need to keep the two questions clear in your head.
BTW, to refer to this as a "match" is somewhat confusing, since it's
not a template match.
I wasn't quite sure how to reference I guess the "selection" the
XPath was trying to achieve - match was the best thing I could come
up with. It was the end of the day and I was frustrated I couldn't
trap the problem when I dashed off the question.
When I fist saw the construct it looked funny and I didn't take time
to analyze what was going on.
thanks
..dan
---------------------------------------------------------------------------
Danny Vint
Panoramic Photography
http://www.dvint.com
voice: 502-749-6179
--~------------------------------------------------------------------
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>
--~--