Re: xpath string index function

On 04/10/11 04:59, Axel Polleres wrote:
> On 3 Oct 2011, at 23:39, Andy Seaborne wrote:
>> I have prototyped:
>>
>> STRBEFORE
>> STRAFTER
>> REPLACE
>>
>> and didn't encountered anything unexpected.
>>
>> I propose adding these as resolution of JB-7 (part 1)
>
>
> +1 to add those
>
> Note that in RIF we also had adopted these additional 3 ones:
>   fn:string-join   ( possible name: STRJOIN )

CONCAT

>   fn:iri-to-uri    ( possible name: IRI_TO_URI )

+0 (AKA I don't mind but don't think it's important)

>   fn:escape-html-uri ( possible name: ESCAPE_HTML_URI )

+0
Again, I really don't see the transformation capabilities as very 
important but I can be persuaded otherwise.  All this "not IRIs" seems a 
bit historical.

>
> Just wanted to ask whether we think those should also be added? (the advantage being that we'd be at least comaptible with the function set in RIF)

I'd like to understand the reasons they were added.  Was it for specific 
reasons / use cases , or based on an audit of F&O?  Compatibility is a 
reasonable reason.

	Andy

>
> best
> Axel
>
>>
>>          Andy
>>
>> On 29/09/11 12:11, Andy Seaborne wrote:
>>> Proposal:
>>>
>>> Add
>>>
>>> SUBSTR_BEFORE (keyword for fn:substring-before)
>>> SUBSTR_AFTER (keyword for fn:substring-after)
>>>
>>> but keep using the XSD F&O operator to back the SPARQL keywords (i.e.
>>> 1-based strings).
>>>
>>> ---------
>>>
>>> It seems to be this, or redo all the string operations as 0-based, and
>>> have URI-calls to fn: string operations for the 1-based style.
>>>
>>> -----
>>>
>>> What about adding fn:replace as well?
>>> REPLACE
>>> http://www.w3.org/TR/xpath-functions/#func-replace
>>>
>>> (I haven't checked the details of the replace language and rules to see
>>> if its sufficiently close to all know programming languages to be easy
>>> to implement via library calls - any one know?)
>>>
>>>
>>> Andy
>>>
>>
>>
>

Received on Tuesday, 4 October 2011 07:57:42 UTC