On 03/07/14 18:31, Joshua TAYLOR wrote:
> Is this an *intended* extension?
It's not intended - ARQ replies on Java's Matcher.replaceAll. It took me
a while to work out why that returns "xx"; I expected "x" but it's once
to replace "foo", once to replace the trailing empty string. The
fn:replace reads like a classic case of a WG not knowing the right
answer and so banning the situation :-)
Matcher does expose all the operations to write ARQ's own replaceAll
with different semantics and documents the replaceAll process in a way
that suggests (to me) that other forms of replaceAll are expected. (Just
need to be a bit careful about implementation - adding addition full
regexs inside the replace loop would not be
Recorded as JENA-740.
Does Virtuoso abort the whole query execution?
select (.. some error... as ?bar) where {}
is a result set of one row, one column, "?bar" and no value. There are
no defined global execution aborts, only static parsing time ones (in an
extended sense - there are some supra-parser static conditions).
--------
| bar |
=======
| |
-------
Andy
The SPARQL function replace is based on XPath's fn:replace, With fn:replace
An error is raised [err:FORX0003] if the pattern matches a zero-length
string, that is, if the expression fn:matches("", $pattern,
$flags)returns true. It is not an error, however, if a captured
substring is zero-length. [1]
<<<
This is the behavior exhibited by Virtuoso. E.g,. running the
following query on the DBpedia endpoint [2] produces an error:
select (replace( "foo", ".*", "x" ) as ?bar) where {}
Virtuoso 22023 Error The regex-based XPATH/XQuery/SPARQL replace()
function can not search for a pattern that can be found even in an
empty string
<<<
Jena accepts it without a problem (for an empty file data.n3):
$ sparql --data data.n3 'select (replace( "foo", ".*", "x" ) as ?bar)
from <> where {}'
--------
| bar |
========
| "xx" |
--------
$ sparql --version
Jena: VERSION: 2.11.0
Jena: BUILD_DATE: 2013-09-12T10:49:49+0100
ARQ: VERSION: 2.11.0
ARQ: BUILD_DATE: 2013-09-12T10:49:49+0100
RIOT: VERSION: 2.11.0
RIOT: BUILD_DATE: 2013-09-12T10:49:49+0100
<<<
Is this an *intended* extension? I ran into while trying to implement
some approximate string matching in pure SPARQL [3]. It's easy enough
to work around (just add a character to the pattern and the string),
but I wasn't sure whether it's a permissible and intentional
extension, or a bug.
//JT
[1] http://www.w3.org/TR/xpath-functions/#func-replace
[2] http://dbpedia.org/sparql
[3] http://stackoverflow.com/q/24557020/1281433
