Re: [Gestalt-users] New extension function

[Colin P. A. <co...@co...>]

>>>>> "Frans" == Frans Englich <fra...@te...> writes:

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

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

Hm. I envisioned passing literal strings - of course a cast is legal,
but it will not happen automatically, so I think your suggestion is
good.

    Frans> Here's a lot of "must" words, but it isn't spec'd what must
    Frans> be done if it fails. What error code is raised if the
    Frans> 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 meant to document them, but forgot to do so. I shall do it.

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

Another good suggestion.

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

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

    Frans> (false(), false(), true(), false(), true())

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

That is true.

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

I don't think that's better at all.

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

But this is an implementation-specific extension function, so there IS
only one implementation.
However, I like the idea of supply a list of ws-separated xs:anyURIs.

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

    Frans> Reads a bit weird.

I'll see if I can improve my wording.

    Frans> (Not that I'm a Gestalt user.)

Thanks for your comments anyway.
-- 
Colin Adams
Preston Lancashire