[
https://issues.apache.org/jira/browse/JENA-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262090#comment-14262090
]
Andy Seaborne commented on JENA-839:
------------------------------------
Caution: It looks like that code extract isn't from the current code base. RDF
1.1 changes have swept through the area. The principle is the same though.
Some background would be useful because there are varfious datatypes that
derive from xsd:string. Where do xsd:normalizedString arise? Maybe we should
be handling (some|all) of those better?
This would affect rather more than {{E_Regex}}. What does the SPARQL spec say?
{noformat}
Node n = SSE.parseNode("'abc'^^xsd:normalizedString") ;
NodeValue nv = NodeValue.makeNode(n) ;
System.out.println(Utils.className(nv)) ;
System.out.println(nv.isString()) ;
System.out.println(n) ;
System.out.println(nv) ;
{noformat}
I'm not sure if {{nv.isString}} is a strong enough test though. It does not
include lang strings.
> E_Regex only works with XSDstring.
> ----------------------------------
>
> Key: JENA-839
> URL: https://issues.apache.org/jira/browse/JENA-839
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 2.12.1
> Environment: Linux
> Reporter: Claude Warren
> Assignee: Claude Warren
>
> E_Regex eval verifies the argument is a string using:
> Node arg = NodeFunctions.checkAndGetStringLiteral("REGEX", args.get(0)) ;
> NodeFunctions.checkAndGetStringLiteral verifies that if the nodevalue is not
> null and is an XSDstring by the following statement:
> if ( dt != null && !dt.equals(XSDDatatype.XSDstring) )
> throw new ExprEvalException(label + ": Not a string literal: " +
> nv) ;
> this means that other string types (e.g. XSDnormalizedString) fail.
> I believe that the check should be to check that dt is an instanceof
> XSDBaseStringType.
> I am looking for comment before making the change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
