Arbitrary schema keys

[RShelley]

I've got a design I'm attempting to define in a JSON schema, but I'm not exactly sure how to represent it.

Our JSON object has a subset of objects with keys that are arbitrary, with an object as their value. For example:

{

...

"stuff" : {

"arbitrary_key_1" : {"some":"stuff"},

"arbitrary_key_2" : {"some":"stuff"},

"other_key_3" : {"some":"stuff"}

}

...

} 

So in this example the keys within the "stuff" object ("arbitrary_key_1", etc) are completely open in the design. The values of those keys, however, are a defined schema object. This may be where the hash "#" is used, but I'm not sure. I don't see in the spec a definition for a hash, and if a hash is used as a wildcard, whether it can be used as a key. I could probably solve this with an array probably, but it's not the implementation design we want (we want to index the key values).

 

 

[Francis Galiegue]

If your keys are arbitrary then you should use additionalProperties:

{
"type": "object",
"additionalProperties:" {
"schema": "for",
"values": "here"
}
}

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

[ryan.s...@12gaugemedia.com]

I'm not sure I understand the "for" and "here" parts. This is what I gathered from some other posts which may or may not be syntactically correct:




"definitions" : {

     "type" : "object",

        "additionalProperties" : {

         "type" : "object",

            "additionalProperties" : {

             "enabled" : {

                 "type" : "boolean",

                 "required" : true

             },

             "address" : {

                    "type" : "string",

                 "required" : true

              }


           }


          }


      }





that could model the following:




"definitions" : {

"foo1" : {

"enabled" : true,

"address" : "blah"

},

"bar2" : {

"enabled" : false,

"address" : "meh"

}

}

[Francis Galiegue]

On Thu, Feb 16, 2012 at 18:28, <ryan.s...@12gaugemedia.com> wrote:
> I'm not sure I understand the "for" and "here" parts.

That was meant to be literal :) "schema for values here". Sorry for
the confusion!

> This is what I gathered from some other posts which may or may not be syntactically correct:
>
> "definitions" : {
>      "type" : "object",
>         "additionalProperties" : {
>          "type" : "object",
>             "additionalProperties" : {
>              "enabled" : {
>                  "type" : "boolean",
>                  "required" : true
>              },
>              "address" : {
>                     "type" : "string",
>                  "required" : true
>               }
>            }
>           }
>       }
>

Your second "additionalProperties" should in fact be "properties".
Inside the "additionalProperties" of the "defintions" keys, it should
read:

{
    "type" : "object",
    "additionalProperties" : {
        "type" : "object",

        "properties" : {

            "enabled" : {
                "type" : "boolean",
                "required" : true
            },
            "address" : {
                "type" : "string",
                "required" : true
            }

        },
        "additionalProperties": false
    }
}

Note the inner additionalProperties defined to false: this disallows
the presence of properties other than "enabled" or "address".

[ryan.s...@12gaugemedia.com]

Yeah, that's what I was thinking as well, I just saw a prior comment from someone else that implied the sub-sub-additionalProperties. Thanks for the clarification!