[
https://issues.apache.org/jira/browse/JENA-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050193#comment-16050193
]
Andy Seaborne commented on JENA-1359:
-------------------------------------
Adding to Dave's comments:
There are two concepts: representation space and value space.
The representation is the pair {{("12.0", xsd:decimal)}}.
The value is mathematical concept of 12 - a point on the number line. Values do
not have a datatype - datatype is part of representation.
The object return of {{Literal.getValue}} is a number, which in java is
{{Number}}, as provided as the most specific type according to Xerces. (It
indicates that this value can be represented by an xsd:int in this case.)
You don't even get the same class for, say, xsd:integer. Java Integer is
limited to 32 bits, Long to 64 bits and after that it is BigInteger.
Treat the return of {{getValue}} as a {{Number}}.
If you want to follow XSD, you might be able to use {{NodeValue}}, part of
ARQ's XSD evaluation sub-system.
If you'd like to suggest an improvement to the Javadoc, then please do. See
JENA-733.
I can understand the expectation especially as {{java.lang.Number}} is
imperfect for large values
Changing this however, is a change to the way Jena has been for many years so
many application might be affected.
The code is in {{org.apache.jena.datatypes.xsd.XSDDatatype}}.
> Literal.getValue() does not respect the datatype
> -------------------------------------------------
>
> Key: JENA-1359
> URL: https://issues.apache.org/jira/browse/JENA-1359
> Project: Apache Jena
> Issue Type: Bug
> Reporter: Panagiotis Papadakos
>
> I was expecting that the getValue would return a Java object based on the
> datatype of typed literals. This is not the case, since jena will coerce a
> decimal literal with value 12.0 to an Integer with value 12.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
