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