Disagreement on current draft v4: "integer" vs "number divisible by 1"

[Francis Galiegue]

Hello,

I have just had an eye at the json-schema github repo and saw this change.

I disagree with this for two reasons, one practical, and the other logical:

* the practical one: integers are used very often in JSON, as much as,
if not more, than decimal numbers;
* the logical one: ANY number, be it decimal or integer, is divisible
by 1, which means you cannot tell apart integers from numbers this
way! Or this means you make { "divisibleBy": 1 } a special case!

I'm sorry to put it so bluntly, but... Not a smart choice, to my eyes.

--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

[Dean Landolt]

On Wed, Dec 28, 2011 at 12:03 PM, Francis Galiegue <fgal...@gmail.com> wrote:

Hello,

I have just had an eye at the json-schema github repo and saw this change.

I disagree with this for two reasons, one practical, and the other logical:

* the practical one: integers are used very often in JSON, as much as,
if not more, than decimal numbers;

There is no notion of integer defined in JSON. In fact, it looks like Crock went out of his way to avoid mentioning it. Obviously there's an int component in the grammar but that's not what parsers are expected to output.

 

* the logical one: ANY number, be it decimal or integer, is divisible
by 1, which means you cannot tell apart integers from numbers this
way! Or this means you make { "divisibleBy": 1 } a special case!

1 is a special case (the multiplicative identity) just as 0 is a special case (as a discontinuity and the additive identity).

Again, JSON doesn't bother with the distinction between integer and real so I'm not convinced JSONSchema needs to either. Is the simple presence of `divisbleBy: <positive-integer>` enough to mark an integer (this circular definition suggests maybe it ain't!)? If you spec integer you kind of have to spec real, right? Still, I tend to agree that there is a real distinction here -- these are in fact two different types. They have a different cardinality (countably vs. uncountably infinite), and technically, a different algebra altogether. Thus, a different set of "characterizing operations" -- to me, that makes them distinct. But this is all probably too academic for the excessively practical JSONSchema.

So if practically is the goal (and I don't know if it is), the question still remains: is it more practical to spec "integer" in terms of other primitives (divisibleBy) or in its own terms entirely (perhaps also specifying "real")? Or would it be more practical to specify type: "integer" as an alias for type: "number", "divisibleBy": 1? This smells an awful lot like a macro expansion -- which would be awesome but probably not too practical :)

[Francis Galiegue]

On Wed, Dec 28, 2011 at 23:52, Dean Landolt <de...@deanlandolt.com> wrote:
[...]

>
>> * the logical one: ANY number, be it decimal or integer, is divisible
>> by 1, which means you cannot tell apart integers from numbers this
>> way! Or this means you make { "divisibleBy": 1 } a special case!
>
>
>
> 1 is a special case (the multiplicative identity) just as 0 is a special
> case (as a discontinuity and the additive identity).
>
> Again, JSON doesn't bother with the distinction between integer and real so
> I'm not convinced JSONSchema needs to either. Is the simple presence of
> `divisbleBy: <positive-integer>` enough to mark an integer (this circular
> definition suggests maybe it ain't!)? If you spec integer you kind of have
> to spec real, right? Still, I tend to agree that there is a real distinction
> here -- these are in fact two different types. They have a different
> cardinality (countably vs. uncountably infinite), and technically, a
> different algebra altogether. Thus, a different set of "characterizing
> operations" -- to me, that makes them distinct. But this is all probably too
> academic for the excessively practical JSONSchema.
>
> So if practically is the goal (and I don't know if it is), the question
> still remains: is it more practical to spec "integer" in terms of other
> primitives (divisibleBy) or in its own terms entirely (perhaps also
> specifying "real")? Or would it be more practical to specify type: "integer"
> as an alias for type: "number", "divisibleBy": 1? This smells an awful lot
> like a macro expansion -- which would be awesome but probably not too
> practical :)
>

I have some other definition of "awesome"...

OK, tell me, with this new scheme, how would you define even numbers?
Short answer: you can't.

[Chris Grant]

I had the same feeling about the divisibleBy(1) 'function.' All
numbers are divisible by one and this doesn't logically lead to an
integer value. I have a feeling that decimal *precision* may be the
better term for this. The divisibleBy(1) thing just feels wrong.

Just my .02.

Thanks,
Chris

On Dec 28, 12:03 pm, Francis Galiegue <fgalie...@gmail.com> wrote:
> Hello,
>
> I have just had an eye at the json-schema github repo and saw this change.
>
> I disagree with this for two reasons, one practical, and the other logical:
>
> * the practical one: integers are used very often in JSON, as much as,
> if not more, than decimal numbers;
> * the logical one: ANY number, be it decimal or integer, is divisible
> by 1, which means you cannot tell apart integers from numbers this
> way! Or this means you make { "divisibleBy": 1 } a special case!
>
> I'm sorry to put it so bluntly, but... Not a smart choice, to my eyes.
>
> --

> Francis Galiegue, fgalie...@gmail.com

[Dean Landolt]

Your point? 

 

OK, tell me, with this new scheme, how would you define even numbers?
Short answer: you can't.

Are you kidding? divisibleBy: 2, of course. This narrows the numeric value space just as minimum or maximum does. Now, if you'd said "there's no way to define odd numbers" you'd be right. But presumably you find this acceptable as this is how it is today.

But you didn't actually address any of the points I made. So I repeat myself: 1 is already inescapably special with regard to divisibleBy, as is 0. Why do you think otherwise? And why do you assume first class integer support should be automatic when JSON itself eschews integers?

[Dean Landolt]

On Wed, Dec 28, 2011 at 8:58 PM, Chris Grant <cdgo...@gmail.com> wrote:

I had the same feeling about the divisibleBy(1) 'function.' All
numbers are divisible by one and this doesn't logically lead to an
integer value. I have a feeling that decimal *precision* may be the
better term for this. The divisibleBy(1) thing just feels wrong.

I don't know -- the notion of divisibleBy: 1 seems to be to be angling at a distinction between reals and integers. XSD defines fractionDigits -- perhaps this would be more appropriate than divisibleBy? XSD also defines totalDigits (your idea of precision). I think both would be useful, and ISTM easier to spec than the divisibleBy concept.

[Chris Grant]

I think we run the risk of people misunderstanding divisibleBy -- just
as I did. It seems that the concept of determining whether a number is
divisible by another number and whether a number fits a particular
number system (real, integer, etc) are two separate concepts.

-CG

On Dec 28, 9:37 pm, Dean Landolt <d...@deanlandolt.com> wrote:

[flavien...@gmail.com]

Then why not a "isMultipleOf" ? or even isModulo ? Checking would be easy (x%y == 0) : and bring stuffs like this : "5.5 % 0.5 == 0" quite easily.

[Francis Galiegue]

On Thu, Dec 29, 2011 at 04:14, Dean Landolt <de...@deanlandolt.com> wrote:
>
[...]
>> >

>> > So if practically is the goal (and I don't know if it is), the question
>> > still remains: is it more practical to spec "integer" in terms of other
>> > primitives (divisibleBy) or in its own terms entirely (perhaps also
>> > specifying "real")? Or would it be more practical to specify type:
>> > "integer"
>> > as an alias for type: "number", "divisibleBy": 1? This smells an awful
>> > lot
>> > like a macro expansion -- which would be awesome but probably not too
>> > practical :)
>> >
>>
>> I have some other definition of "awesome"...
>
>
> Your point?
>

My point is simple: integer is a nice, simple way, of telling that the
entity is a number without any decimal digit. This allows JSON Schema
implementations to process numeric data efficiently. And computers are
much faster at dealing with integers than they are with decimals. And
having to specify disivibleBy to constrain the number type is not only
counterproductive, it is unnatural, illogical _and_ ineffective. The
fact that JSON itself does not distinct between integers and numbers
is not relevant. This is JSON Schema, not the JSON specification.

>>
>> OK, tell me, with this new scheme, how would you define even numbers?
>> Short answer: you can't.
>
>
> Are you kidding? divisibleBy: 2, of course. This narrows the numeric value
> space just as minimum or maximum does. Now, if you'd said "there's no way to
> define odd numbers" you'd be right. But presumably you find this acceptable
> as this is how it is today.
>

4.4 is divisible by 2. 4.4 is not an even number.

> But you didn't actually address any of the points I made. So I repeat
> myself: 1 is already inescapably special with regard to divisibleBy, as is
> 0. Why do you think otherwise? And why do you assume first class integer
> support should be automatic when JSON itself eschews integers?
>

See above as to why JSON not defining integers or numbers is
irrelevant to my eyes. And again, 1 is special since for any real
number n, 1 divides n. Any REAL number. Everybody knows that. Why
going against the common logic? XSD has done enough damage, let's not
go this way. As to 0, it is not allowed for divisibleBy, so the point
is moot.

Just for "fun", I have implemented it this way for a project of mine
which deals with tens of megabytes of data: since I have to process
one keyword more, I lose 10% in performance. Far from being
negligible. And this is in spite of the fact that I cache validators.

[Francis Galiegue]

On Thu, Dec 29, 2011 at 04:14, Dean Landolt <de...@deanlandolt.com> wrote:
[...]
>

> Now, if you'd said "there's no way to
> define odd numbers" you'd be right.
>

Actually there is:

{
"type": "integer",
"disallow": [ { "divisibleBy": 2 } ]

[Dean Landolt]

On Thu, Dec 29, 2011 at 8:58 AM, Francis Galiegue <fgal...@gmail.com> wrote:

On Thu, Dec 29, 2011 at 04:14, Dean Landolt <de...@deanlandolt.com> wrote:
[...]
>

>  Now, if you'd said "there's no way to
> define odd numbers" you'd be right.
>

Actually there is:

{
   "type": "integer",
   "disallow": [ { "divisibleBy": 2 } ]

}

Right -- I'd forgotten about disallow because negation is so problematic (all subtypes should be covariant but disallow opens the door to possible contravariance). Of course, by your logic any rational number is divisible by 2 -- if 4.4 is than so is 3. This is quite obviously not what divisibleBy was intended to mean, so as you demonstrate here divisibleBy is far too confusing for specification.

Again, what do people think of totalDigits and fractionDigits? This gets us precision and integers in a nice little package.

[Chris Grant]

Using totalDigits and fractionDigits, I would guess the simplest way
to define the desire for an integer number would be to set
fractionDigits to zero. Is this correct?

I like the idea of fractionDigits more than divisibleBy. What benefit
is there to having totalDigits? Would minimum/maximum cover that
functionality?

-CG

On Dec 29, 8:50 am, Dean Landolt <d...@deanlandolt.com> wrote:
> On Thu, Dec 29, 2011 at 8:58 AM, Francis Galiegue <fgalie...@gmail.com>wrote:

>
> > On Thu, Dec 29, 2011 at 04:14, Dean Landolt <d...@deanlandolt.com> wrote:
> > [...]
>
> > >  Now, if you'd said "there's no way to
> > > define odd numbers" you'd be right.
>
> > Actually there is:
>
> > {
> >    "type": "integer",
> >    "disallow": [ { "divisibleBy": 2 } ]
> > }
>
> Right -- I'd forgotten about disallow because negation is so problematic
> (all subtypes should be covariant but disallow opens the door to possible

> contravariance). Of course, by your logic *any rational number*is

[Dean Landolt]

On Thu, Dec 29, 2011 at 10:31 AM, Chris Grant <cdgo...@gmail.com> wrote:

Using totalDigits and fractionDigits, I would guess the simplest way
to define the desire for an integer number would be to set
fractionDigits to zero. Is this correct?

Yes. 

 

I like the idea of fractionDigits more than divisibleBy. What benefit
is there to having totalDigits? Would minimum/maximum cover that
functionality?

No, it's about precision, e.g. both 345 and 3.45 have 3 total digits.

[Francis Galiegue]

On Thu, Dec 29, 2011 at 16:31, Chris Grant <cdgo...@gmail.com> wrote:
> Using totalDigits and fractionDigits, I would guess the simplest way
> to define the desire for an integer number would be to set
> fractionDigits to zero. Is this correct?
>
> I like the idea of fractionDigits more than divisibleBy. What benefit
> is there to having totalDigits? Would minimum/maximum cover that
> functionality?
>

What would be their default value? -1 to say "I don't care"?

[Dean Landolt]

On Thu, Dec 29, 2011 at 11:42 AM, Francis Galiegue <fgal...@gmail.com> wrote:

On Thu, Dec 29, 2011 at 16:31, Chris Grant <cdgo...@gmail.com> wrote:
> Using totalDigits and fractionDigits, I would guess the simplest way
> to define the desire for an integer number would be to set
> fractionDigits to zero. Is this correct?
>
> I like the idea of fractionDigits more than divisibleBy. What benefit
> is there to having totalDigits? Would minimum/maximum cover that
> functionality?
>

What would be their default value? -1 to say "I don't care"?

Perhaps, though -1 would really just be a sigil, no different than if their domain was defined as nullable. Amusingly you'd still want type: "integer" or something like it to define their domain in the metaschema :)

Again, integers and reals are different beasts, sibling types perhaps (they have a different algebra). I never said I don't want integer just that integer can't be defined in a vacuum, and defining it is a bit of a slippery slope.

[Francis Galiegue]

(I'm not sure I understand "metaschema", can you elaborate?)

Well, I can see the interest for fractionDigits: setting it to 0 would
indeed define an "integer" as it is currently defined.

As the draft currently stands anyway, integer is gone. I am reluctant
to make it completely gone from my implementation (for draftv4 and up
only, obviously) until this matter is settled...

Also, I see that "format" is gone. This is another tricky one... I
actually like format a lot, since it defines precisely the contents of
an item (maybe I say this because I fully implement them all, except
for "style" -- yes, I even have "color" covered fully). Is it
scheduled that it will be reintroduced in some other separate
specification?

[Dean Landolt]

On Thu, Dec 29, 2011 at 2:05 PM, Francis Galiegue <fgal...@gmail.com> wrote:

On Thu, Dec 29, 2011 at 18:27, Dean Landolt <de...@deanlandolt.com> wrote:
>
>
> On Thu, Dec 29, 2011 at 11:42 AM, Francis Galiegue <fgal...@gmail.com>
> wrote:
>>
>> On Thu, Dec 29, 2011 at 16:31, Chris Grant <cdgo...@gmail.com> wrote:
>> > Using totalDigits and fractionDigits, I would guess the simplest way
>> > to define the desire for an integer number would be to set
>> > fractionDigits to zero. Is this correct?
>> >
>> > I like the idea of fractionDigits more than divisibleBy. What benefit
>> > is there to having totalDigits? Would minimum/maximum cover that
>> > functionality?
>> >
>>
>> What would be their default value? -1 to say "I don't care"?
>
>
> Perhaps, though -1 would really just be a sigil, no different than if their
> domain was defined as nullable. Amusingly you'd still want type: "integer"
> or something like it to define their domain in the metaschema :)
>
> Again, integers and reals are different beasts, sibling types perhaps (they
> have a different algebra). I never said I don't want integer just that
> integer can't be defined in a vacuum, and defining it is a bit of a slippery
> slope.
>

(I'm not sure I understand "metaschema", can you elaborate?)

The metaschema is just the schema that defines jsonschema.

Well, I can see the interest for fractionDigits: setting it to 0 would
indeed define an "integer" as it is currently defined.

 

Yeah, without any of the confusion about trying to define division -- it seems simpler from a specification standpoint.

 

As the draft currently stands anyway, integer is gone. I am reluctant
to make it completely gone from my implementation (for draftv4 and up
only, obviously) until this matter is settled...

Also, I see that "format" is gone. This is another tricky one... I
actually like format a lot, since it defines precisely the contents of
an item (maybe I say this because I fully implement them all, except
for "style" -- yes, I even have "color" covered fully). Is it
scheduled that it will be reintroduced in some other separate
specification?

--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To post to this group, send email to json-...@googlegroups.com.
To unsubscribe from this group, send email to json-schema...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.

[Francis Galiegue]

On Thu, Dec 29, 2011 at 21:11, Dean Landolt <de...@deanlandolt.com> wrote:
[...]
>>

>> (I'm not sure I understand "metaschema", can you elaborate?)
>
>
> The metaschema is just the schema that defines jsonschema.
>

Which is itself a JSON schema ;)

I can see it defined with fractionDigits, not with "divisibleBy": 1. I
can even cook it up if you are interested.

[Paul d'Aoust]

Correct me if I'm wrong, but isn't 'divisibleBy' supposed to use
modulo for its truth test? To my understanding, this would be the
truth test for divisibleBy (if x is the value to be tested and y is
the divisibleBy value):

!(x % y)

Therefore, given x of 4.4 and y of 2 (or 1, for that matter), x would
fail the test.

Perhaps we should have 'precision' rather than 'fractionDigits'. I
think this might be a better word, because (1) it's a word that people
are accustomed to using, and (2) it's faster to type :-) Like people
have already said, precision would give us bounds ('precision 0' would
map to 'integer', and 'precision 2' would allow us to specify money, a
feature which is missing from the current definition, unless you
consider 'divisibleBy 0.01', which is perhaps unnecessarily baroque)
and would also satisfy those who feel uncomfortable about creating
extra 'types' that don't exist in the JSON specification. 'integer' is
indeed the only made-up type, which I suspect is why it got taken out
of the spec. (I remember coming across that issue when I was writing a
JS-based validator.)

I dunno; I know that 'precision' and 'divisibleBy' can replace
'integer'. But I think 'precision' (or 'fractionDigits') feels more
natural than 'divisibleBy' because while the latter covers both use
cases, I think it's a bit too clever, and we want to remain practical!

I recognise that 'precision' is simply an abstraction of
'divisibleBy' (divisibleBy = 1 ^ -precision) , but I argue that it's a
useful abstraction, because it makes for a more human-readable schema.

(Actually, in terms of human-readableness, I'm personally in favour of
having both 'integer' and 'number'. I know you have to invent a new
fake type, but it's simple to understand and maps to types in a number
of different languages. Yes, it does add constraints that JSON never
intended, but hey -- that's what JSON-Schema is all about, isn't it?)

Paul d'Aoust

On Dec 29, 12:29 pm, Francis Galiegue <fgalie...@gmail.com> wrote:

> On Thu, Dec 29, 2011 at 21:11, Dean Landolt <d...@deanlandolt.com> wrote:
>
> [...]
>
>
>
> >> (I'm not sure I understand "metaschema", can you elaborate?)
>
> > The metaschema is just the schema that defines jsonschema.
>
> Which is itself a JSON schema ;)
>
> I can see it defined with fractionDigits, not with "divisibleBy": 1. I
> can even cook it up if you are interested.
>
> --

> Francis Galiegue, fgalie...@gmail.com

[Paul d'Aoust]

Hmm, ignore my closing comment -- after giving it some thought, I
think that creating an extra type to handle integral cases is a bit
weird. If anything, maybe something like 'numberFormat' could be
created. But the more I think about it, the more I realise that
'precision: 0' is perfectly adequate. I realise that it resurrects the
'maxDecimal' rule that was struck out at revision 2, but I think maybe
it should be resurrected? It does create overlapping functionality,
but then, so does 'type: any' and 'patternProperties' and a couple of
the different 'format's, which could just be specified with a
'pattern' rule instead. The way I understand it, in the schema,
overlapping functionality is acceptable when it makes things easier
for us.

Here's a question: what's the 'any' type for, anyway? If no 'type'
rule is specified, then 'any' is implied, and 'disallow: any' doesn't
make sense either, does it? Is it just there to make things more
obvious for someone who might be reading my schema?

Thanks,
Paul

[Greg Olszewski]

On 12/28/2011 02:52 PM, Dean Landolt wrote:

So if practically is the goal (and I don't know if it is), the question still remains: is it more practical to spec "integer" in terms of other primitives (divisibleBy) or in its own terms entirely (perhaps also specifying "real")? Or would it be more practical to specify type: "integer" as an alias for type: "number", "divisibleBy": 1? This smells an awful lot like a macro expansion -- which would be awesome but probably not too practical :)

 

I'm sorry to put it so bluntly, but... Not a smart choice, to my eyes.

What purpose does divisibleBy serve?

Maybe it'd be best to remove it from the specification. My validator silently ignores divisibleBy.


Greg

[Gary Court]

The "divisibleBy" attribute specifies the value that any number
instance must divide into without any remainder. In most computer
languages, this would be defined as:

(instanceValue % divisibleBy) == 0

The value of 1 for the "divisibleBy" attributes represents the entire
set of all integers.

Attributes like "totalDigits", "fractionDigits", "precision",
"maxDecimal" have been removed/ignored in the past for they assume the
number is in base 10 format. The "divisibleBy" attribute is much more
powerful/flexible than these.

However, being that there is some confusion over the naming of this
attribute, and that it will now be used more frequently, perhaps a
more simple name such as "mod" might be more appropriate.
{"type":"number", "mod":1}

--Gary

[Francis Galiegue]

On Tue, Jan 3, 2012 at 04:44, Gary Court <gary....@gmail.com> wrote:
> The "divisibleBy" attribute specifies the value that any number
> instance must divide into without any remainder. In most computer
> languages, this would be defined as:
>
> (instanceValue % divisibleBy) == 0
>
> The value of 1 for the "divisibleBy" attributes represents the entire
> set of all integers.
>

This is very counterintuitive, especially since JSON defines numbers, and...

> Attributes like "totalDigits", "fractionDigits", "precision",
> "maxDecimal" have been removed/ignored in the past for they assume the
> number is in base 10 format.

it defines numbers as a sequence of digits between 0 and 9, with an
optional fractional part, which is also composed of digits between 0
and 9.

What are these if not base 10 numbers?

So, where is the problem?

"precision", as proposed, is much more sensible imho. But defining
integer doesn't cost much and is more powerful than divisibleBy alone,
not to mention more intuitive.

--
Francis Galiegue, fgal...@gmail.com

[Paul C. Bryan]

I'd tend to agree if we were working with fixed-point numbers here, but for all intents and purposes, they're floats. Precision doesn't make much sense (to me) because this assumes that all decimal numbers can be represented, which they can't.

Paul

[Dean Landolt]

On Tue, Jan 3, 2012 at 11:57 AM, Paul C. Bryan <paul....@forgerock.com> wrote:

I'd tend to agree if we were working with fixed-point numbers here, but for all intents and purposes, they're floats. Precision doesn't make much sense (to me) because this assumes that all decimal numbers can be represented, which they can't.

In javascript, sure. But JSON isn't just javascript, and the lexical space it defines does in fact support a whole range of number types.

[Francis Galiegue]

On Tue, Jan 3, 2012 at 17:57, Paul C. Bryan <paul....@forgerock.com> wrote:
> I'd tend to agree if we were working with fixed-point numbers here, but for
> all intents and purposes, they're floats.

Disagree. They are floats _for JavaScript_.

I do server side validation and can validate (nearly) any decimal
number, even with divisibleBy, in the "natural sense" (any real number
is divisible by another if the remainder of the division is 0) because
I use a language which doesn't have to make do with IEEE 754
limitatons like JavaScript (even a 64bit float cannot represent such a
simple number as 0.1).

And nothing in the spec restrict JSON Schema to JavaScript. In fact,
the closest mention to JavaScript in all the spec is the use of ECMA
262 for regexes -- which I also happen to do.

[Joe Littlejohn]

Francis, I'm really glad you've kicked off some more discussion here.
I'd also like to see a more intuitive alternative to divisiblyBy.
There are obviously many ways to skin this cat, each with their own
merits. For now though, I'd like to steer this discussion back to the
original topic because I think it's an important one.

I'm strongly in favour of leaving the type 'integer' intact.
{"type":"number", "divisibleBy":1} is excessively verbose, ugly and
ambiguous.

In practice, real world JSON documents contain a lot of integers.
Browse the API docs for a some of the high profile, publicly
accessible APIs and you'll see that integers are commonplace. We use
integers heavily in our internal services (no surprise I'm sure),
hence we use {"type":"integer} regularly in almost all our JSON
schemas.

Having to define these properties using {"type":"number",
"divisibleBy":1} is downright tedious and doesn't feel right when
we're working with a format that is famously terse for good reason.
JSON Schema is already losing the brevity war when compared to
alternatives like JSchema. Integer may technically be a redundant type
but the practical implications of removing it are downright awful.

Omitting 'integer' from draft 04 would be a mistake. Can we have it
back in please?

[Xample]

What should us be expecting for the Draft 5 at last ?

[penduin]

Just to toss in my opinion:  "type": "integer" should stay;  "divisibleBy": 1 is weird.

In practical terms, WJElement (my JSON/JSON-schema library) doesn't even support floating-point values right now, since the need has yet to come up in any of our data.  So, we treat "number" and "integer" the same.  But come the day we do support floats, looking specifically for "divisibleBy": 1 instead of just looking at "type" to tell them apart would seem very hackish and weird.

[Richie Vos]

Mathematically, 0.35 is divisible by 1. It's also devisable by 2, 3, 4, 4.35, ...

Integer is a proper mathematical set. Divisible by seems like an operator on that set.

http://en.wikipedia.org/wiki/Integer

So +1 to integer

On Sep 6, 2012 1:36 PM, "penduin" <owen...@gmail.com> wrote:

Just to toss in my opinion:  "type": "integer" should stay;  "divisibleBy": 1 is weird.

In practical terms, WJElement (my JSON/JSON-schema library) doesn't even support floating-point values right now, since the need has yet to come up in any of our data.  So, we treat "number" and "integer" the same.  But come the day we do support floats, looking specifically for "divisibleBy": 1 instead of just looking at "type" to tell them apart would seem very hackish and weird.

--
 
 

[Xample]

Let's say that "multipleOf" would be more appropriated, again the reason for this choice is that there is no integer in javascript. (And as a reminder the json schema means "javascript object notation schema")

[Francis Galiegue]

Yes, but JSON is not JavaScript. Tying JSON Schema to this or that
particular language would be, to my eyes, a mistake.

As we are talking about numbers, I also remind that the JSON RFC does
not specify a limit on the number of digits in the fraction part
and/or decimal part of numeric instances.

--
Francis Galiegue, fgal...@gmail.com
JSON Schema: https://github.com/json-schema

[Andrei Neculau]

+1

integer should stay

[Sebastian Lasse]

Any news on this ?

The current spec. for "multipleOf" still says "number" ...

Am Mittwoch, 28. Dezember 2011 18:03:30 UTC+1 schrieb fge:

Hello,

I have just had an eye at the json-schema github repo and saw this change.

I disagree with this for two reasons, one practical, and the other logical:

* the practical one: integers are used very often in JSON, as much as,
if not more, than decimal numbers;
* the logical one: ANY number, be it decimal or integer, is divisible
by 1, which means you cannot tell apart integers from numbers this
way! Or this means you make { "divisibleBy": 1 } a special case!

I'm sorry to put it so bluntly, but... Not a smart choice, to my eyes.

--
Francis Galiegue, fgal...@gmail.com