[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Avoiding boneheaded mistakes in XSLT?

Subject: Re: Avoiding boneheaded mistakes in XSLT?
From: Dave Pawson <davep@xxxxxxxxxxxxx>
Date: Wed, 29 Dec 2010 17:38:07 +0000
Re:  Avoiding boneheaded mistakes in XSLT?
On Wed, 29 Dec 2010 10:31:21 -0500
"G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:


> >Again you're assuming the presence of a schema?
> 
> I am not, Dave.  My claim is that given only the input XML instance 
> it is unwarranted to emit any kind of error or warning for an XPath 
> address that does not resolve to the instance.
> 
> >Review that given an input XML instance only.
> 
> That is my original intent of what I wrote above.
> 
> >The lack of a trigger for the xpath provides information
> >that is useful IMHO.
> 
> I wholeheartedly disagree.  It is misleading information.  That an 
> element allowed to be absent is absent is not worthy of any message 
> at all. 

"allowed"? I'd interpret that as a validity statement wrt some schema?



> It is entirely an expected condition of the input instance 
> that my stylesheet may test for, or get the value for, or select 
> without an error.
> 
> For example, rather than:
> 
>    <xsl:if test="c">
>      <newC>This is a new c: <xsl:value-of select="c"/></newC>
>    </xsl:if>
> 
> I usually will type:
> 
>    <xsl:for-each select="c">
>      <newC>This is a new c: <xsl:value-of select="."/></newC>
>    </xsl:for-each>
> 
> There are three examples of addressing the absent <c> in my instance, 
> with a test, a value-of and a select, and just because <c> isn't in 
> my instance the processor has no license to issue any error or 
> warning message.  The next instance may, very well, have a <c>
> element in it.

So for some C you will have errors/unmatched xpaths
others you won't. 
  I'd prefer to know of them rather than 'assume'
they are OK. 



> >just that in many cases such a schema may not be available,
> >an instance being used is more usually available.
> 
> Absolutely an instance is more available, but because an instance 
> knows nothing of absent items that are allowed to be absent, the 
> processor cannot make an assumption that addressing something that is 
> absent is worthy of an error or warning message.
> 
> I hope this has finally convinced you.

No Ken, I'm looking at it as a means of getting more from the processor.
If as in your example/Schematron, the warning is something that I can
tick off, then great. Otherwise it's likely I've done something wrong
in writing that xpath expression.

Same problem, different perspectives.




-- 

regards 

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.