Re: [xsl] XPath that returns nothing

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Hi,

On 9/29/2011 6:30 AM, David Carlisle wrote:
> adding
> <xsl:if test="*[2] or not(definition)">
> <xsl:message>.....
>
> in lots of places makes the transformation resemble a schematron schema
> more than a transformation at times (and probably the xslt engine spends
> as long doing those checks as anything else), but having the messaging
> inserted at the point that the transformation fails (often an
> xsl:otherwise or match="*" default case) rather than have a separate
> schematron try to second-guess what input the transformation can validly
> handle means that the error reporting is more accurate, and (perhaps)
> more likely to get run every time.

I agree. Plus, when this gets to be a normal thing, one ends up with 
constructs such as

<xsl:variable name="unexpected" select="not(count(definition) eq 1)"/>
<xsl:apply-templates mode="erroneous" select=".[$unexpected]"/>

with the "erroneous" mode handling all the messaging (and possibly 
discriminating between different error conditions).

The bottom line is that this is one of the areas where one finds that 
engineering a transformation to work well in a pipeline introduces a new 
set of requirements, all by itself.

Cheers,
Wendell

--
======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================