Re: [xsl] Uncontrolled navigation around a document using @* ... huh?

[Michael Kay <mike@xxxxxxxxxxxx>]

The principle in the spec is that streamability is determined entirely by
static analysis. The spec allows vendor extensions (that is, things that can
be streamed even though not guaranteed streamable according to the spec), and
some of the extensions in Saxon in fact handle situations that cannot be
determined statically, at least in the absence of a schema. A classic example
is <xsl:value-of select="//title"/>, which is non-streamable if one title
contains another within its subtree; this is non-streamable according to the
spec, but Saxon handles it optimistically, using buffering where necessary in
the rare event that one title does actually contain another.

I haven't introduced any pragmas or streamability assertions yet, but it's
certainly a possibility. So far we've found that most use cases can be handled
just by declaring the types of variables and parameters.

Michael Kay
Saxonica


On 14 Nov 2013, at 11:25, Michael Sokolov <msokolov@xxxxxxxxxxxxxxxxxxxxx>
wrote:

> On 11/14/13 5:58 AM, Michael Kay wrote:
>> What we are saying in the latest draft is that f:convert(@code) is
streamable provided the function signature of f:convert() declares its
argument with an atomic type. If it doesn't declare the type, streaming fails.
This interacts with the rules for packages, which say that when you override a
function in another package, the signature must be compatible.
>>
> Are you providing a pragma or something of the sort so programmers can
declare their functions streamable, and raise a runtime error if it turns out
not to be the case?  Or is streamability entirely determined at compile-time?
>
> -Mike