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('"',p:base-uri(//p:identity[1]),'"')" >> >> </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.comReceived on Monday, 27 April 2009 11:36:50 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 11:36:51 GMT