Strong preference for proposal 2.
My preference would be to introduce separate notes for each reference formulation wherein these details can be described.

Then that means that some test cases need to be adapted (e.g., some JSON values have integer values that should be transformed as such). And somebody creating those notes, of course.

Strong preference for proposal 2.
My preference would be to introduce separate notes for each reference formulation wherein these details can be described.

+1

+1 for proposal 2

+1 for proposal 2, but in line with the respective specs, JSON has following primitive types:

• strings -> xsd string
• numbers -> xsd double (or float? I would not suggest to specify integer IF parses as integer OR double IF parses as double, you can override the datatype in RML)
• booleans --> xsd bool
• null: NULL

for XML: why not take over the datatype as specified in XML (sure it'll be XSD in most cases, but all other cases should also be covered no?)

The datatype for XML without a schema would be a string and one of the schemas if it can be looked up. XML data types only "exist" in the schema. XML DTDs, another XML schema language, only has character data which are strings. The problem, however, is that you then have two cases:

• the XSD is referred to AND available (for download)
• basic case when no schema is available

I believe core should support the basic case, and IO could handle both

I feel this issue is already being addressed in the rml-io-registry repository, right? Or do we want a default/basic behaviour in the rml-core? @pmaria