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(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
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(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--