I need to validate that a property in an object only contains values
from a list specified in an array earlier in that object. Any ideas on
why the schema below isn't working?
On Mon, Apr 16, 2012 at 20:26, Dan <dan.gottl...@gmail.com> wrote: > Hi,
> I need to validate that a property in an object only contains values > from a list specified in an array earlier in that object.
Unfortunately, you cannot do that. The JSON specification does not specify any key order, therefore JSON APIs offer no guarantee in this regard either. And consider the following (valid) JSON fragment:
{ "key1": "value1", "key1": "value2"
}
You cannot know in advance what the value of "key1" will be.
-- Francis Galiegue, fgalie...@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)
On Tue, Apr 17, 2012 at 11:29, Francis Galiegue <fgalie...@gmail.com> wrote:
[...]
> { > "key1": "value1", > "key1": "value2" > }
> You cannot know in advance what the value of "key1" will be.
To make matters even worse, I recall trying at some point a JSON API written in Java which, in such an event, would return an _array_ of the different values for the key... Which is evidently bizarre, but _does not_ contradict the JSON specification either. Bah.
Anyway, if you do want to do this and use server-side validation, my API can do what you request: you just have to write your own keyword validators, and you can do that.
-- Francis Galiegue, fgalie...@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)
On Tuesday, April 17, 2012 5:29:15 AM UTC-4, fge wrote:
> On Mon, Apr 16, 2012 at 20:26, Dan wrote:
> > Hi,
> > I need to validate that a property in an object only contains values
> > from a list specified in an array earlier in that object.
> Unfortunately, you cannot do that. The JSON specification does not
> specify any key order, therefore JSON APIs offer no guarantee in this
> regard either. And consider the following (valid) JSON fragment:
> {
> "key1": "value1",
> "key1": "value2"
> }
> You cannot know in advance what the value of "key1" will be.
> -- > Francis Galiegue, fgalie...@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)
Wait a minute, I think that your original question could work, I mean, you are close, because if I hard code in
["one", "two"] for your reference: {"$ref": "#ruleTargets"} then all is fine (yes: the "Valid Data" example is valid, and the "Invalid Data" is invalid). The problem is just something to do with how the $ref is evaluated into an array of schemas. Have you tried a full path to the JSON URI, (i.e. {"$ref": "http://domain.com/path/to/valid_data.json#/ruleTargets"} )?
On Tue, Apr 17, 2012 at 5:09 PM, <dan.gottl...@gmail.com> wrote: > Thanks Francis - that's disappointing, but makes sense.
> On Tuesday, April 17, 2012 5:29:15 AM UTC-4, fge wrote:
>> On Mon, Apr 16, 2012 at 20:26, Dan wrote:
>> > Hi,
>> > I need to validate that a property in an object only contains values >> > from a list specified in an array earlier in that object.
>> Unfortunately, you cannot do that. The JSON specification does not >> specify any key order, therefore JSON APIs offer no guarantee in this >> regard either. And consider the following (valid) JSON fragment:
>> You cannot know in advance what the value of "key1" will be.
>> -- >> Francis Galiegue, fgalie...@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)
> To post to this group, send email to json-schema@googlegroups.com. > To unsubscribe from this group, send email to > json-schema+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/json-schema?hl=en.
On Tue, Apr 17, 2012 at 23:34, N. Morse <nmo...@academiccatalog.com> wrote: > Wait a minute, I think that your original question could work, I mean, > you are close, because if I hard code in
> ["one", "two"] > for your reference: > {"$ref": "#ruleTargets"} > then all is fine (yes: the "Valid Data" example is valid, and the > "Invalid Data" is invalid). > The problem is just something to do with how the $ref is evaluated > into an array of schemas.
The problem to start with is that enum takes an array as an argument (possibly empty BTW), and each element in the enum is not a schema, but a JSON document which the value must match. For instance:
If you actually want a value to match one schema among many, you have to use the "type" keyword:
{ "type": [ { // schema 1 here }, { // schema 2 here }, // etc ]
}
-- Francis Galiegue, fgalie...@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)
Sorry I miss-spoke, I meant to say and array of "elements", not "schema" But it I understand the original question "ref for enum", it boils down to: "Can {"$ref": "#ruleTargets"} refer to an element in an arbitrary JSON document?" Because if it can, then the original example in this thread should work. --Nate
On Wed, Apr 18, 2012 at 3:09 AM, Francis Galiegue <fgalie...@gmail.com> wrote: > On Tue, Apr 17, 2012 at 23:34, N. Morse <nmo...@academiccatalog.com> wrote: >> Wait a minute, I think that your original question could work, I mean, >> you are close, because if I hard code in
>> ["one", "two"] >> for your reference: >> {"$ref": "#ruleTargets"} >> then all is fine (yes: the "Valid Data" example is valid, and the >> "Invalid Data" is invalid). >> The problem is just something to do with how the $ref is evaluated >> into an array of schemas.
> The problem to start with is that enum takes an array as an argument > (possibly empty BTW), and each element in the enum is not a schema, > but a JSON document which the value must match. For instance:
> -- > Francis Galiegue, fgalie...@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-schema@googlegroups.com. > To unsubscribe from this group, send email to json-schema+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.
On Wed, Apr 18, 2012 at 15:35, N. Morse <nmo...@academiccatalog.com> wrote: > Sorry I miss-spoke, I meant to say and array of "elements", not "schema" > But it I understand the original question "ref for enum", it boils down to: > "Can {"$ref": "#ruleTargets"} refer to an element in an arbitrary JSON > document?" > Because if it can, then the original example in this thread should work.
OK, so: yes, "$ref" can refer to an arbitraty JSON document (even a non existing one for that matter). But no, the example won't work. This is because the enum keyword itself does not work this way. The contents of enum is a JSON array:
[ d1, d2, .... ]
where d1, d2, etc are themselves JSON documents -- documents, _not_ schemas.
Right now, "$ref" is really meant to only refer to schemas within schemas -- which means JSON documents pointed to by "$ref" _must_ be valid schemas as well. Extending its role the way you describe would require modifying the spec a great deal, as this would not only affect the enum keyword. In fact, I suspect this cannot be done but cannot give an example as to why at the moment.
-- Francis Galiegue, fgalie...@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)
Thanks Francis, I appreciate your explanation, although it is disappointing that $ref cannot substitute in the JSON array (as required by the enum:) right now. I accept that it cannot be done (now! or ever?), but If in time, you do find a reason why this cannot (ever) be done, I would be interested in some (counter) example. much thanks, --Nate Morse
On Wed, Apr 18, 2012 at 9:48 AM, Francis Galiegue <fgalie...@gmail.com> wrote: > On Wed, Apr 18, 2012 at 15:35, N. Morse <nmo...@academiccatalog.com> wrote: >> Sorry I miss-spoke, I meant to say and array of "elements", not "schema" >> But it I understand the original question "ref for enum", it boils down to: >> "Can {"$ref": "#ruleTargets"} refer to an element in an arbitrary JSON >> document?" >> Because if it can, then the original example in this thread should work.
> OK, so: yes, "$ref" can refer to an arbitraty JSON document (even a > non existing one for that matter). But no, the example won't work. > This is because the enum keyword itself does not work this way. > The contents of enum is a JSON array:
> [ d1, d2, .... ]
> where d1, d2, etc are themselves JSON documents -- documents, _not_ schemas.
> Right now, "$ref" is really meant to only refer to schemas within > schemas -- which means JSON documents pointed to by "$ref" _must_ be > valid schemas as well. Extending its role the way you describe would > require modifying the spec a great deal, as this would not only affect > the enum keyword. In fact, I suspect this cannot be done but cannot > give an example as to why at the moment.
> -- > Francis Galiegue, fgalie...@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-schema@googlegroups.com. > To unsubscribe from this group, send email to json-schema+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.
On Wed, Apr 18, 2012 at 19:03, N. Morse <nmo...@academiccatalog.com> wrote: > Thanks Francis, I appreciate your explanation, although it is > disappointing that $ref cannot substitute in the JSON array (as > required by the enum:) right now. > I accept that it cannot be done (now! or ever?), but > If in time, you do find a reason why this cannot (ever) be done, I > would be interested in some (counter) example. much thanks, > --Nate Morse
Your proposal would make $ref a fully fledged JSON Reference. I think this is a good idea for draft v4. Comments?
-- Francis Galiegue, fgalie...@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)
On Thu, Apr 19, 2012 at 00:52, Francis Galiegue <fgalie...@gmail.com> wrote:
> Well, in fact, I don't see one.
OK, I do see one. URIs are supposed to be resolved relative to the current schema's URI. As such, "#whatever" will try to look for "#whatever" in the schema, _not_ the JSON document being validated...
-- Francis Galiegue, fgalie...@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)
Ok, You are saying that local references are within the schema itself, so "local reference" will not work for Dan's example. So, if he references another document#/value like { "$ref": "http://example.com/example.json#/foo/bar" } ... Then, there is no problem that I can see. --Nate On Apr 18, 2012 6:54 PM, "Francis Galiegue" <fgalie...@gmail.com> wrote:
> On Thu, Apr 19, 2012 at 00:52, Francis Galiegue <fgalie...@gmail.com> > wrote:
> > Well, in fact, I don't see one.
> OK, I do see one. URIs are supposed to be resolved relative to the > current schema's URI. As such, "#whatever" will try to look for > "#whatever" in the schema, _not_ the JSON document being validated...
> -- > Francis Galiegue, fgalie...@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-schema@googlegroups.com. > To unsubscribe from this group, send email to > json-schema+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/json-schema?hl=en.
On Thu, Apr 19, 2012 at 13:37, N. Morse <nmo...@academiccatalog.com> wrote: > Ok, You are saying that local references are within the schema itself, so > "local reference" will not work for Dan's example. So, if he references > another document#/value like > { "$ref": "http://example.com/example.json#/foo/bar" } > ... Then, there is no problem that I can see.
_IF_ "$ref" is really meant to be a JSON reference. The wording in the current specification (as far as I read it) doesn't really say that, and therefore it cannot be really counted upon...
Another trick was mentioned on this list by Flavien Volken, which is to use external validation services via $ref:
which is a very pretty hack. If you have this, you can make a service return a schema, say, like this:
{ "enum": [ "list", "of", "values" ]
}
which would pretty much have the same effect.
-- Francis Galiegue, fgalie...@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)
