Re: [xsl] Correct way to test for no match

Subject: Re: [xsl] Correct way to test for no match
From: Dan Vint <dvint@xxxxxxxxx>
Date: Mon, 05 Oct 2009 18:33:37 -0400
At 12:52 PM 10/5/2009, you wrote:


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[@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[@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,


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.



Danny Vint

Panoramic Photography

voice: 502-749-6179

Current Thread