Claude,
I've applied a fix to jena-security and I wanted to make sure that it's
the right fix and that I haven't uncovered something else.
A typical example of a test failure for RDF 1.1 is
testGetFloat[C:true R:true U:true D:true force:true] ==>
java.lang.NumberFormatException: For input string: "literal"
-----------------------------
The change is because getFloat in LiteralImpl is slightly inconsistent
in behaviour:
@Override
public float getFloat() {
if (isPlainLiteral()) {
return Float.parseFloat(getLexicalForm());
} else {
return asNumber(getValue()).floatValue();
}
}
The jena-security input is "literal"^^xsd:string. The closest match in
RDF 1.1 is "plain literals" includes xsd:strings.
parseFloat throws java.lang.NumberFormatException,
asNumber throws DatatypeFormatException
The test harness silently catches DatatypeFormatException, but not
NumberFormatException.
I've changed the catcher to:
catch (final DatatypeFormatException | NumberFormatException e )
Theer are similar cases for char and boolean.
Simple literals are not tested as far as I can see. Is that right?
Andy