patternProperties - required pattern match

[Matthew Painter]

Hi all,

Looking at the RFC, there seems to be no way currently of specifying
that each property name in an object must match a (or at least one)
key of the patternProperties object in the schema.

I am looking to implement an object whose keys have to be of a certain
format, and I was hoping to use patternProperties, but without the
above I am not sure how I can do it?

Any feedback gratefully received :)

Thanks

Matt

[Francis Galiegue]

The rule is that for an object, the value of a property with name "xx"
must match a schema set defined as follows (and yes, I've had
difficulty understanding that at first):

* if "xx" is strictly equal to an entry in "properties", then its
value must obey the associated schema;
* if "patternProperties" exists, then the value of "xx" must also
match any schema for which "xx" matches one of "patternProperties"
(and note that "matches" here means matching in the **real** regex
sense: regex "p" matches "p", "ape", "proctor" and "mishap" -- if you
want your regex anchored, make it anchored);
* if AND ONLY IF the set of schemas is empty at this point, then "xx"
must match the schema associated with "additionalProperties" (if not
present, an empty schema).

It should be noted that:

* if additionalProperties is false, if the schema set is empty after
step 2, it means the JSON document is invalid: "xx" could not satisfy
any of "properties" or "patternProperties";
* if "xx" matches an entry in "properties", it DOES NOT prevent it to
have to consider patternProperties if present.

--
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)

[Matthew Painter]

Hi Francis,

Thanks for the input :)

From what your saying + the RFC there is no way I can see to ensure that all property names have a specific format without specifying all the property names and setting additionalProperties = false? 

Say I want to validate an object with integer keys (as strings), and number values.

If you:

• set propertyPatterns = { '^[0-9]+$' : { "type" : "number" } }
• set additionalProperties = false
• set properties = {}

Then an object { '123' : 12.3 } will not validate by the RFC? In fact, the only object which will validate is the empty object {}?

However, if you:

• set propertyPatterns = { '^[0-9]+$' : { "type" : "number" } }
• set additionalProperties = true
• set properties = {}

Then { '123' : 12.3 } will validate (yay!),  { '123' : 'a' } won't (yay!) but so will { '123' : 12.3, 'a' : 'b' }, which I don't want to (boo!) :)

Any ideas on if this is something in draft3 which is just not possible? This is what I think right now :/

Thanks!

Matt

--
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.

[Xample]

Hi, as I understood :

• set propertyPatterns = { '^[0-9]+$' : { "type" : "number" } }
• set additionalProperties = false
• set properties = {}

Will validate { '123' : 12.3 } as "123" will match '^[0-9]+$' and therefore be associated to AT LEAST one property (in which case we will not apply the fallback additionalPropertes rule)

The implementation is :

- Is my key associated to at least one property in "properties" or "propertyPattens" ?

   - if yes then we are done (i.e. validate through all those corresponding associated properties scheme).

   - if no, then is the additionalProperties == false ?

      - if yes then validation fail for the key… (it is not described anywhere and not allowed)

      - if no, then apply the "additionalProperties" rules (if available, but at least do not fail)

[Matthew Painter]

Aha! Ok, well I'll do some testing using JSV and check that my interpretation of the RFC is wrong :)

Thanks!

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.

To view this discussion on the web visit https://groups.google.com/d/msg/json-schema/-/7jTT9BCkdrcJ.

[Francis Galiegue]

On Tue, Jan 17, 2012 at 12:31, Matthew Painter
<matthew...@kusiri.com> wrote:
> Aha! Ok, well I'll do some testing using JSV and check that my
> interpretation of the RFC is wrong :)
>
> Thanks!
>

You should note that defining properties is NOT compulsory. You can
just define patternProperties and additionalProperties alone.

If I can give you an advice, when you encounter an object type and it
is allowed at this point, it is first to validate the object structure
(ie, the set of keys) before validating the values. If you have { "a":
2 }, you know it cannot validate since "^[0-9]+$" doesn't match "a".

(also, ECMA 262 supports \d, which is shorter than [0-9])