RE: [XSLT 2.0] Seeking clarification about static typing feature

Let's quote the paragraph in full:

Note: There is no conformance level or feature defined in this specification
that requires implementation of the static typing features described in
[XPath 2.0]. An XSLT processor may provide a user option to invoke static
typing, but to be conformant with this specification it must allow a
stylesheet to be processed with static typing disabled. The interaction of
XSLT stylesheets with the static typing feature of XPath 2.0 has not been
specified, so the results of using static typing, if available, are
implementation-defined.

Firstly, it's a note. Therefore it doesn't place any normative requirements
on a processor. Instead, it's there primarily to point out some things that
the specification *doesn't* say.

Static typing, in the sense of the XPath/XQuery formal semantics, means
*pessimistic* static typing. For example, under static typing it's a static
error to call "number(PRICE)" unless there is sufficient schema information
available to prove that the path expression PRICE will deliver at most one
element. In the absence of that information, you have to call "number(PRICE
treat as element())" or number(zero-or-one(PRICE)). This means in practice
[my opinion here!] that static typing is pretty unusable unless you have a
schema for every document (including temporary trees), and also (in the XSLT
case) unless you write all your match patterns to make schema types
explicit, for example <xsl:template match="schema-element(INVOICE)">.

This isn't the same as reporting dynamic type errors early, something I
refer to as *optimistic* static typing. For example, processors can report
the type error in "substring(current-date(), 1, 4)" at compile time (and
Saxon does so) because there is no way this construct can ever succeed: it
will inevitably fail.

We haven't actually defined [pessimistic] static typing semantics for XSLT.
It could be done, and there are people who would like to do it, but we
haven't had sufficient resources. However, there are static typing semantics
for XPath. The note quoted above is pointing out that we don't actually say
you aren't allowed to implement the XPath static typing semantics in XSLT,
but we're saying that if you do, it should be optional, and the way it works
in an XSLT context is essentially implementation-defined, because we haven't
defined the type inferencing rules for each XSLT construct in the same way
as the formal semantics does for XQuery and XPath. This rule means that
writing "number(PRICE)+3" is portable: no-one can claim that in order to
write a portable stylesheet, you have to write "number(PRICE treat as
element())+3". A processor can provide a strict type-checking mode that will
pick up "number(PRICE)+3" as a potential error, but you can switch this mode
off.

I hope this clarifies the implications of the Note.

Michael Kay
(personal response)
  

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of Colin 
> Paul Adams
> Sent: 06 September 2005 18:10
> To: public-qt-comments@w3.org
> Subject: [XSLT 2.0] Seeking clarification about static typing feature
> 
> 
> I am confused about the note in section 21 that says a stylesheet must
> be allowed to be processed with static typing disabled.
> Since XML Path Language says that an implementation may raise type
> errors during the static analysis phase, even if it doesn't implement
> the Static Typing Feature, I can't see what the impact of this is.
> 
> Could someone please provide some illustrative examples of how this
> can make a difference (not necessarily in the drafts, just in reply to
> this message will be fine).
> 
> Thank you. 
> -- 
> Colin Adams
> Preston Lancashire
> 
>

Received on Thursday, 8 September 2005 08:30:48 UTC