objectPropertyDefinition to be split into actual types?

[wzr1337]

Do we want to split objectPropertyDefinition into several subtypes?

According to spec, I see the following

• float
• integer
• reference
• string
• boolean
• customType
• array of:
  • float
  • integer
  • reference
  • string
  • boolean
  • customType

Only a float would have a resolution, only numeric types would have units etc.

More clarity, but is is needed?

Opinions please...

[ghost]

float and integer are no native JSON types.

http://json-schema.org/latest/json-schema-core.html#rfc.appendix.B

Note that the concept of "integer" is from a vocabulary, not the data model

http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.2

A numeric instance is valid only if division by this keyword's value results in an integer.

If we consider using float or integer, we must have a referencable definition in the meta-schema. Defining floats can be tricky because floats are usually differently defined per compiler, parser, CPU-architecture.

[sen542]

I would not define new elementary types which do not have "a native" expression/equivalent in JSON. So, please forget "float". "array of" is yet defined. Does it need any change or extension? Custom types add new flexibility but they are not really needed. If yes, their depth should be limitted. Otherwise we will get lost in nested custom types.

[wzr1337]

JSON schema only knows number, which supersets integer and float the viwi/RSI spec reads:

number vs integer JSON does not allow non-numbers like NaN, nor does it make any distinction between integer and floating point. If the format integer is used in this document or the object definitions, the meaning is that a service will send and expect integer values. The parsing must be compatible with parsing a number into an integer, because there is no distinction during transfer (on the wire). If the format is defined as number, neither client nor service may parse it as an integer.

how do we deal with that if we do not want to have a distinction between integer and float in the validation scheme?

[sen542]

Hm, actually this kind of differentiation is not needed any longer if you add additional object details like "resolution", similar to minimum and maximum which are yet there for properties of type number. That may lead to a changed proposal from ym side: remove integer, float etc. and keep number only.

[sen542]

In my understanding we are done with this discussion. New types are not needed; even "integer" may be removed if "resolution" becomes mandatory in the schema as soon as a property of type "number" is defined.