Re: Extension candidates
Robert Koberg <[email protected]> Fri, 19 Dec 2008 13:03:26 -0500
| Newsgroups | gmane.text.xml.xslt.extensions |
|---|---|
| Message-ID | <[email protected]> |
On Dec 19, 2008, at 12:24 PM, John Snelson wrote:
> Florent Georges wrote:
>> John Snelson wrote:
>> Hi John,
>>> http://snelson.org.uk/~jpcs/higher-order-functions.html
>>> As Michael says, it might be appropriate for EXSLT to attempt
>>> something simpler than this proposal - but it will hopefully give
>>> people something to think about.
>> It is indeed very interesting!
>> First two little questions (a bit OT here, sorry): 1/ it seems it
>> is not possible to create a function item from a dynamic QName, is
>> it on purpose? (I guess so),
>
> I hadn't thought about making it dynamic. The problem with doing so
> would mainly be that the implementation could know very little about
> the type of a function whose name was not known at compile time. I
> guess I'd need to see a use case for being able to do that.
(I really don't know what I am talking about, but...). Here is what I
was thinking:
x:call($procFuncNs, $func, $argSeq)
Where it might result in:
x:call("http://oracle/ns", "get-parameter", ("paramName"))
x:call("http://oracle/ns", "get-parameter", ("paramName", "defaultVal"))
x:call("http://exist/ns", "get-parameter", ("paramName"))
x:call("http://exist/ns", "get-parameter", ("paramName", "defaultVal"))
x:call("http://saxon/ns", "get-parameter", ("paramName"))
x:call("http://saxon/ns", "get-parameter", ("paramName", "defaultVal"))
>
>
>> and 2/ what's the difference between
>> both following item types (from the type hierarchy in "1 Function
>> Items")?
>> function()
>
> This means any function item (any arity, arg type and result type).
>
>> function() as item()*
>
> This means a function item that takes no arguments and returns a
> sequence of items.
>
>> About possible simplifications, I think the most obvious are
>> changes to the grammar. Some can be changed to extra extension
>> functions (for example a function that returns a function item
>> instead of literals,) other are more touchy (like inline
>> functions.) Some concrete proposals:
>> - do not define the extension to ItemType, and do not define the
>> exact type of a function item (can be defined as it were a new
>> type of items, but no assumption nor test can be made about the
>> real type of such items);
>> - define a function to create function items instead of literals
>> (should the name of the function by a real QName item, or a
>> QName literal?);
>> - do not define inline functions (at least in a first time);
>> - define a function ex:call() for 1.3 Dynamic Function
>> Invocation.
>
> That sounds reasonable.
>
> John
>
> --
> John Snelson, Oracle Corporation http://snelson.org.uk/john
> Berkeley DB XML: http://oracle.com/database/berkeley-db/xml
> XQilla: http://xqilla.sourceforge.net
> _______________________________________________
> exslt mailing list
> [email protected]
> http://www.exslt.org/list