Re: Inconsistancy between documentation and conformance tests with respect to STRBEFORE() & STRAFTER()

Peter,

This is a a change-in-progress, the tests and the editors' working draft 
have been updated.

http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml

notes a change since second last call:

[[
    Non-matching return in STRBEFORE and STRAFTER
    changed to be the empty simple literal always.
]]

Details:

http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#func-strbefore
http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#func-strafter

 > STRBEFORE("日本語"@ja,”s”) = ””
 > What’s the correct response?

No match - now returns the empty string, without lang tag.

 > STRAFTER(“abc”,””) = “abc”
 > STRAFTER(“abc”@en,””) = “abc”@en
 > STRAFTER(“abc”^^xsd:string,””) = “abc”^^xsd:string

The empty string matches at the start.

 > However, this contradicts the specification, which states that the
 > result should be an empty string if arg2 is the empty string.

The editors working draft currently says that the empty string is 
considered to be a match at teh end for STRAFTER, returning arg1.

I hope this answers your comment - I would be be grateful if you would 
confirm this with a reply to this list.

 Andy 



On 28/06/12 21:03, Peter Waher wrote:
> Hello
>
> Perhaps you’ve already discussed this in previous messages, or corrected
> it somehow. I just wanted to point it out, and/or receive your thoughts
> about the matter:
>
> http://www.w3.org/TR/sparql11-query/#func-strbefore
>
> To me, there seem to be two inconsistencies between the specification
> and the conformance tests:
>
> The first is how STRBEFORE() or STRAFTER() handles the case of language
> literals in first parameter, and the second parameter not found. There’s
> also no example showing how to interpret this, and the tests interpret
> it differently for the two functions:
>
> According to the *strbefore01a* conformance test (which is declared as
> Not Classified),
>
> STRBEFORE("日本語"@ja,”s”) = ””
>
> (i.e. a simple literal with the empty string, without language tag).
> This violates this statement in the specification: “The function returns
> a literal of the same kind (simple literal, plain literal same language
> tag, xsd:string) as the first argument |arg1|.”.
>
> Later in the text, it states that if the string is not found, it should
> only return an “empty string”, without stating if this means a simple
> literal, overriding the previous statement that it should be of the same
> type as arg1. Then it re-uses the phrase “empty string” again: “If the
> lexical form of |arg2|is the empty string, the lexical form of the
> result is the emprty string.”. In this case, the specification shows
> that “empty string” in this case is not a simple literal, but a literal
> of the same type as arg1 (as shown in the typed literal example following.).
>
> What’s the correct response? A simple literal (regardless of type of
> arg1)? Or an empty string of the same type as arg1?
>
> The second inconsistence, this time in the specification (the test is
> the logical one here), is *strafter02 *(also Not Classified). Here:
>
> STRAFTER(“abc”,””) = “abc”
>
> STRAFTER(“abc”@en,””) = “abc”@en
>
> STRAFTER(“abc”^^xsd:string,””) = “abc”^^xsd:string
>
> However, this contradicts the specification, which states that the
> result should be an empty string if arg2 is the empty string. However,
> the logical response is to return the entire string again. In this way
> CONCAT(STRBEFORE(?s,?x),STRAFTER(?s,?x)) would return ?s with the first
> occurrence of ?x removed, even if ?x is the empty string.
>
> Thanks for your time,
>
> Sincerely,
>
> Peter Waher
>

Received on Saturday, 30 June 2012 12:58:02 UTC