W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2012

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

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sat, 30 Jun 2012 13:57:32 +0100
Message-ID: <4FEEF7BC.8010801@epimorphics.com>
To: public-rdf-dawg-comments@w3.org

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


notes a change since second last call:

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



 > 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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:30 UTC