RE: Using Saxon 8.5 and collection() to process a dir

With extension attributes, the WG has pinned down quite carefully what they
can and can't do. It's easier in that case, because the effect of evaluating
the stylesheet in the absence of the extension attribute is well-defined.
This isn't true for extension functions, so it's much harder to define the
boundaries as to what they can and can't do. There's always wriggle room for
implementors. I can say that the effect of discard-document is to modify the
URI-to-document mapping in the dynamic context so that the document URI is
now bound to a different document (in terms of node identity); it's hard for
anyone to write a definition of side-effects that excludes that. Or I could
say that the effect of discard-document is to convert a document into a
flocument, a kind of object that is entirely outside the scope of the W3C
specifications.

But that's all legalese. The practical point is that the extension function
mechanism is there to enable vendors to provide extensions for the benefit
of people who want the extra functionality and are prepared to pay the price
in portability. So whatever the small print says, it's entirely within the
intent of the spec.

(I've actually considered implementing discard-document() so that it frees
the memory, but remembers the node-ids and reuses them if the same document
is ever reloaded. Decided it wasn't worth the hassle: just another
opportunity for introducing bugs. And you'd still have no guarantee that
requesting the same URI later on gives you the same content: something that
the new collection URIs also suffer from, incidentally.)

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: Colin Paul Adams [mailto:colin@xxxxxxxxxxxxxxxxxx] 
> Sent: 04 August 2005 20:28
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re:  Using Saxon 8.5 and collection() to 
> process a directory of XML files
> 
> >>>>> "Michael" == Michael Kay <mike@xxxxxxxxxxxx> writes:
> 
>     Michael> 18.1.2 says: "There is no prohibition on calling
>     Michael> extension functions that have side-effects."
> 
>     Michael> There's nothing that limits the nature of the
>     Michael> side-effects.
> 
> Except there's nothing that states these side effects are allowed to
> override other provisions of the standard (in this case, the node
> identity of document nodes for a given document URI).
> 
>     Michael> sacrificing portability, and I'm prepared to interpret
>     Michael> the spec liberally if it's the only way to deliver
>     Michael> functionality that users need. If you don't like it,
>     Michael> don't use the extension.)
> 
> That's fine, if a function that causes deviation from standard
> behaviour is clearly marked.
> 
> What concerns me, is that if 18.1.2 gives license to change any
> provisions of the standards, then this ought to be clearly spelled out
> (it certainly isn't clear to me). And if that isn't the intention of
> the working group as a whole, then it should probably also be spelled
> out.
> -- 
> Colin Adams
> Preston Lancashire