RE: [xsl] An interesting angle on types in XSLT 2.0?

Mike, *please* don't cross-post to xsl-list and public-qt-comments. People
can only reply to both if they are subscribed to both (using the same email
address), so the thread is bound to fragment. In any case, the lists have
different audiences and so the same reply isn't necessarily appropriate on
both.

As an engineer, I find it difficult to relate to W. E. Perry's philosophical
language. Your practical point, however, is that that type errors should be
recoverable. While it would be feasible to define a recovery action for many
type errors (in effect, by casting the supplied value to the required type)
this would lose all the benefits of type safety that we have introduced into
the language, as well as introducing another source of non-interoperability,
and in my view it would be a bad idea. We see too many cases where the
implicit type conversions of XSLT 1.0 produce results that users find
baffling, and with the increased range of types available in XSLT 2.0, this
problem would get significantly worse.


Michael Kay

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

Received on Monday, 19 May 2003 05:33:19 UTC