Re: Extension function prefixes/namespace

I think the problem I'm running into is an implementation not a spec issue.

The *implementation* (Saxon) I'm using is done by re-declaring the 
namespace prefix to be bound to the function class.
Thus by the time the select= expression is evaluated, the "p" namespace 
has been redeclared 'under the hood' and it no longer
refers to "http://www.w3.org/ns/xproc" but rather "java:classname..."
Thus it in fact doesnt work.  

But I agree, its a implementation, not a spec issue.   I've since 
discovered Calabash doesnt have this problem because it uses a different 
mechanism for declaring global functions in xpath and I'm looking into 
using that method.

-David


>> Looking into this further, I am coming to the conclusion that
>> extension functions should NOT share the same prefix as any schema
>> being processed by the processor.
>> For example is this *input* document to xproc pipeline parsable.
>>
>> <p:pipeline 'xmlns:p=http://www.w3.org/ns/xproc'>
>> <p:identity/>
>> </p:pipeline>
>>
>> By this xproc pipeline
>>
>> <p:pipeline 'xmlns:p=http://www.w3.org/ns/xproc'>
>>  <p:string-replace match="p:pipeline">
>>  <p:with-option name="replace"
>> select="concat('&quot;',p:base-uri(//p:identity[1]),'&quot;')"
>>
>> </p:string-replace>
>> </p:pipeline>
>>
>> note the use of the same prefix in replace,  the function and the argument
>>     
>
> That should work just fine. The function "base-uri" is identified by a
> QName who's namespace URI is "http://www.w3.org/ns/xproc" and who's
> local name is "base-uri".
>
>                                         Be seeing you,
>                                           norm
>
>   

-- 
-----------------------------------------------------------
David A. Lee
dlee@calldei.com  
http://www.calldei.com