[
https://issues.apache.org/jira/browse/JENA-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282552#comment-14282552
]
Andy Seaborne commented on JENA-839:
------------------------------------
Using {{nv.isString()}} (testing whether the value space is compatible with
xsd:string) is better than {{instanceof}} (which is about java representation
(an implementation choice) and also about derived datatypes (not restrictive on
the value space)).
This is really considering custom extensions and slightly odd implementation
choices so the difference is really quite minor - a custom datatype could have
a value space xsd:string without being java-inheriting from
{{XSDBaseStringType}}.
Checked for RDF 1.1 usage.
The one corner case is {{rdf:langString}}. Its value space is a set of pairs
strings and language tags -- use of explicit {{^^rdf:langString}} can therefore
only result in an illegal value (no language tag).
> 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
> Fix For: Jena 2.12.2
>
>
> E_Regex eval verifies the argument is a string using:
> {noformat}
> Node arg = NodeFunctions.checkAndGetStringLiteral("REGEX", args.get(0)) ;
> {noformat}
> NodeFunctions.checkAndGetStringLiteral verifies that if the nodevalue is not
> null and is an XSDstring by the following statement:
> {noformat}
> if ( dt != null && !dt.equals(XSDDatatype.XSDstring) )
> throw new ExprEvalException(label + ": Not a string literal: " +
> nv) ;
> {noformat}
> 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)
