Re: [Gestalt-users] New extension function

[Frans E. <fra...@te...>]

On Friday 14 July 2006 16:27, Colin Paul Adams wrote:
> Here is my current specification for a proposed new extension
> function, to be written this weekend. Comments welcome.
>
>
> gexslt:transformation
>
> This function allows you to run an XSLT transformation from within your
> current XSLT transformation. Syntax is:
>
> gexslt:transformation ($trans as xs:anyURI,

As far as I know the current practice is to have arguments taking URIs be of 
type xs:string(so one can pass string literals) but require the lexical space 
to conform to xs:anyURI. I think it's sensible.

> $initial-context as node()?, 
> $initial-template as xs:QName?, $initial-mode as xs:QName?, $parameters as
> item*, $flags as xs:boolean*) as item()+ or gexslt:transformation ($trans
> as xs:anyURI, $initial-context as node()?) as item()+
>
> The two-argument form is equivalent to passing () for all remaining
> arguments.
>
> The meaning of the arguments is as follows:
> The URI of the transformation to be run An optional initial context node An
> optional initial template An optional initial mode

Here's a lot of "must" words, but it isn't spec'd what must be done if it 
fails. What error code is raised if the conditions aren't reached?

> The parameters list must consist of an even number of items. The odd
> numbered items must be of type xs:QName, which represent the name of a
> global stylesheet parameter. The following even-numbered item will be the
> value of that stylesheet parameter.

I would use two lists for this, where one is the names and the other the 
values. This makes type checking possible in an ordinary fashion, and it 
makes the spec simpler.

> The flags all default to false(). Trailing flags may be omitted, which
> means I can easily add further flags later. The meaning of the flags
> currently defined is as follows: No flags are defined at this stage. I have
> various stylesheet-caching control flags in mind.

Hm, booleans aren't very readable for switches. For example:

(false(), false(), true(), false(), true())

What is what? That's especially hard to tell when someone else is reading the 
code or some time have passed since writing it.

Using letters is a step better, like flags for fn:tokenize() and so on.

However, I would prefer a whitespace separated list of xs:anyURIs where it is 
implementation defined which that are recognized(and where unrecognized are 
ignored). In this way any implementation can add performance settings in a 
portable way.

> The result sequence has one of two forms: Exactly one xs:QName,
> representing an error code from the transformation One or
> moredocument-node().

Reads a bit weird.

(Not that I'm a Gestalt user.)


Cheers,

		Frans