[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Avoiding boneheaded mistakes in XSLT?


Subject: Re: [xsl] Avoiding boneheaded mistakes in XSLT?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 29 Dec 2010 10:31:21 -0500

At 2010-12-29 15:23 +0000, Dave Pawson wrote:
On Wed, 29 Dec 2010 10:07:26 -0500
"G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:

>  Allow me to try again, please.
>
> Consider an XML document whose content model for <a> is:  ( b, c?, d )
>
> This is a valid instance:
>
>    <a>
>      <b/>
>      <c/>
>      <d/>
>    </a>
>
> But, this is also a valid instance:
>
>    <a>
>      <b/>
>      <d/>
>    </a>
>
> So, given the second instance, I run it against two stylesheets:
>
> Stylesheet 1:
>
>    <xsl:if test="not(a/c)">I'll make an assumption about a missing
> C</xsl:if>
>
> Stylesheet 2 (with a typo in it because the user mistyped):
>
>    <xsl:if test="not(a/cc)">I'll make an assumption about a missing
> C</xsl:if>
>
> Without a schema to know that <cc> is not an acceptable element,
> there is no way to distinguish the two above if statements.  With a
> schema, the second one is clearly in error.  But without a schema, it
> does not make sense to issue an error or warning about the first
> stylesheet, because it is a bona fide test I want to perform
> regarding the absence of <c>.  Hence, it cannot make the same
> assumption about the second stylesheet, and so again cannot issue an
> error or warning.


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. 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.

I'm not arguing that extra information may be gleaned from the Schema,

Nor am I. When a schema is present, an error or warning message of an XPath expression addressing an item that isn't defined in the schema will be very helpful to users, especially users of UBL who don't realize they've typed <cbc:CitySubDivisionName> instead of <cbc:CitySubdivisionName>.


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.

. . . . . . . . . . Ken


-- Contact us for world-wide XML consulting & instructor-led training Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx Legal business disclaimers: http://www.CraneSoftwrights.com/legal


Current Thread
Keywords