[
https://issues.apache.org/jira/browse/JENA-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263497#comment-14263497
]
Andy Seaborne commented on JENA-839:
------------------------------------
Yes - I think that makes the best sense. The operations are value-space
operations so the key is the returned value is right even if the datatype
chosen is not the minimal choice. Type promotion of derived types happens
elsewhere (xsd:byte+xsd:byte is xsd:integer regardless of the the value
produced).
Detailed reading seems to suggest xsd:normalizedString is unusual in that
string operations don't destroy the invariant. It's not true for other derived
types of xsd:string e.g. xsd:token where a substring may have whitespace at the
start or finish so it is not a legal token.
It also makes the output type static like the byte case. That makes at least
explainable.
> 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:
> {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)
