Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


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

From: Dan Vint <dvint@-----.--->
To: xsl-list@-----.------------.---
Date: 10/5/2009 10:34:00 PM
At 12:52 PM 10/5/2009, you wrote:


>>unparsed-entity-uri(ancestor::ipb/figure/subfig/graphic[@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[@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,
>
>unparsed-entity-uri(ancestor::ipb/figure/subfig/graphic[@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@l...>
--~--



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent