Use of native types in from/to RDF

[lanthaler]

We discussed this in issue #100 and decided to

RESOLVED: Introduce a 'useNativeTypes' flag for the fromRDF algorithm which, when set, attempts to convert xsd:boolean, xsd:integer, and xsd:double to native JSON values. If the conversion fails the value will be converted to the expanded object notation form.

@dlongley then proposed to

... consider something slightly different for the flags to fromRDF:

For fromRDF we could have four flags: @type, @integer, @double, @boolean.

Each of these flags would have the following default values:

@type => rdf:type
@integer => xsd:integer
@double => xsd:double
@boolean => xsd:boolean

These flags could be set to any property desired -- or set to null to prevent conversion. This would also replace the notType flag; you would just set @type to null.

We could simplify the @double and @boolean flags to: @number: ["xsd:double", "xsd:integer"] but the analogy isn't there for toRDF; we'll probably want the same flags there to indicate how to convert existing native types into RDF.

I then replied:

Good idea. But I would change the names of the flag @integer, @double, and @boolean to just integer, double, and boolean or perhaps even better to integerNumber and floatNumber to highlight that there's not a 1:1 type match.

I would be fine with having integerNumber/floatNumber in toRDF() and just number in fromRDF().

Furthermore, I think we should have a flag which controls whether an exception is thrown if the conversion to native types fails or whether in that case the result should just remain in expanded form.

and that

If we decide to introduce the flags Dave proposed in #100 we probably should use the printf("%1.15E", number) representation only if numbers with fractions are really mapped to xsd:double (which would be the default).

We should decide whether we should go down that path or stick to the useNativeTypes flag.

[lanthaler]

RESOLVED: Continue to support useNativeDatatypes in fromRDF(), specifying how the native type conversion happens. Do not support options for overriding each native datatype with a different value.

NOTE: If this feature needs to be added in the future, it can be done without creating any backwards-compatability issues.

[msporny]

The resolution for this issue, including the modification to the fromRDF() algorithm has now been added to the spec.