Re: An interesting angle on types in XSLT 2.0?

----- Original Message ----- 
From: "W. E. Perry" <wperry@xxxxxxxxxxxxx>


> substitute 'interpreted' or 'expected' for 'used'). That distinction is
> fundamental:  the separation of well-formedness from validity is
> philosophically the salient point on which XML departs from its SGML ancestry.
> Therefore proliferation in the forms of validation which might be applied to
> XML (though each naturally introduces new errors of its own) is on the whole a
> good thing. Forcing any such class of errors so intimately into the core of
XML
> that the fundamental distinction of well-formedness from validation is lost or
> obscured is transgression upon XML itself.

Hey all,

I believe XSLT 2.0 implementations will be compelled to this sin by the
following language in

http://www.w3.org/TR/2003/WD-xslt20-20030502/

***

2.9 Error Handling

Certain errors are classified as type errors. A type error occurs when the value
supplied as input to an operation is of the wrong type for that operation, for
example when an integer is supplied to an operation that expects a node. If a
type error occurs in an instruction that is actually evaluated, then it must be
signaled as a dynamic error. An implementation may also, optionally, signal a
type error as a static error, even if it occurs in part of the stylesheet that
is never evaluated, provided it can establish that execution of a particular
construct would never succeed.

It is implementation-defined whether type errors are signaled statically.
For example, the following construct contains a type error, because 42 is not
allowed as an operand of the xsl:apply-templates instruction. An implementation
may optionally signal this as a static error, even though the offending
instruction will never be evaluated, and the type error would therefore never be
signaled as a dynamic error.

<xsl:if test="false()">
  <xsl:apply-templates select="42"/>
</xsl:if>

If more than one error arises, an implementation is not required to signal any
errors other than the first one that it detects. It is implementation-dependent
which of the several errors is signaled. This applies both to static errors and
to dynamic errors. An implementation is allowed to signal more than one error,
but if any errors have been signaled, it must not finish as if the
transformation were successful.

***

If the last sentence quoted is modified to:  ". . . though if any type errors
have been signaled, it *is implementation-dependent whether to* finish as if the
transformation were successful. . . .", I and many others can be satisfied that
an essential feature of the current rec is not being deprecated.

Mr. Kay has demonstrated a work-around that is not too burdensome, but a I think
a responsible, presentation-oriented implementation can and should be permitted
to treat this as a recoverable error, as defined.


sincerely,

Mike Haarman,
Developer and Information Architect,
Infinite Campus


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list