- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 15 Sep 2008 15:19:46 +0100
- To: Henry S. Thompson <ht@inf.ed.ac.uk>
- Cc: public-xml-processing-model-comments@w3.org, Dan Connolly <connolly@w3.org>, mozer <xmlizer@gmail.com>
On 15 Sep 2008, at 14:55, Henry S. Thompson wrote: > Jeni Tennison writes: >> On 15 Sep 2008, at 09:54, Henry S. Thompson wrote: >>> Dan Connolly writes: >>> >>>> Whether they are aliases of XPath 1.0 or XPath 2.0 functions >>>> makes no difference; they're still aliases. >>> >>> I think perhaps you misunderstood. There _is no_ XPath 1.0 function >>> which has the relevant behaviour. So we have defined an extension >>> function _for XPath 1.0_ whose functionality is defined to be the >>> XPath 1.0 equivalent of an XPath 2.0 function. >> >> Perhaps Dan's point is that we should use the XPath 2.0 function >> namespace (http://www.w3.org/2005/xpath-functions) for those >> functions >> rather than co-opting them into our own namespace. > > I thought of that, but that's sort of wrong, isn't it? The function > we want is not actually/exactly the function whose name is > http://www.w3.org/2005/xpath-functions:base-uri, because that is a > function defined > > a) with input a node in an XPath 2 data model > and > b) value an xs:anyURI or NULL > > whereas the function we are defining has > > a) input an infoitem > and > b) output a string. Ah, good point. (Although the function we're defining takes an XPath 1.0 node rather than "an infoitem", which isn't a concept in XPath 1.0.) Similarly, p:resolve-uri() returns a string rather than an xs:anyURI value. Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Monday, 15 September 2008 14:31:31 UTC