Seeking clarification on a few JSONSchema points
Matthew W
I've just been investigating the latest drafts of this standard and
pleased to see it's coming along well!
I've noticed some inconsistent usage in the meta-schemas themselves
when it comes to specifying the schema of an object. I'm seeing all
three of the following syntaxes in use:
"schema": "/some/url"
"schema": {"$ref": "/some/url"}
"$schema": "/some/url"
So which is it to be? :)
I'm also a bit concerned about how the JSON referencing standard is
specified and the way this is intertwined with the self-describing
spec for json-schema.
For example I notice that the http://json-schema.org/json-schema
metaschema is an instance of http://json-schema.org/hyper-schema,
which in turn extends http://json-schema.org/json-ref.
But this would only give a schema-specified meaning to the use of json
referencing properties on the top-level object (as I understand it),
and not specify its meaning when used in arbitrary nested positions
(which it is used at in the meta-schemas).
Some possible solutions:
* Specify json referencing separately as a lower layer, underlying
standard - a kind of external include mechanism / data-structure
reference serialising mechanism which forms a standard of itself on
top of json. Then define the json-schema stuff on top of json-ref.
This seems like the cleanest approach if you're happy to be fully
dependent on json-ref.
* Add some features to json-schema to specify where json references
may or may not be used, allowing their use in nested positions in
schemas (including the metaschemas) to be fully described and specced.
This feels potentially a little messy to me but might work.
I feel like the apparent attempt to make json-ref 'not special' and
just an instance of link relations specified by hyper-schema, hasn't
quite succeeded at present though. It's still being treated as
'special', if you get what I mean, since the nested uses of json
references aren't covered by the metaschema.
Ultimately I feel like a decision needs to be made - either there's a
firm, hard, well-defined dependency of json-schema on an underlying
json-ref layer - or should find a way to drop the dependency on json-
ref in order to use json-schema. This might mean explicitly specifying
a simpler referencing mechanism (could be a subset of json-ref) as
part of json-schema for the kinds of references that json-schemas need
to use.
My personal preference would be for this latter option, since then I
don't need to implement all of json-ref in order to support json-
schema.
Cheers
-Matt
Kris Zyp
On 5/26/2010 5:22 AM, Matthew W wrote:
Hey there
I've just been investigating the latest drafts of this standard and
pleased to see it's coming along well!
I've noticed some inconsistent usage in the meta-schemas themselves
when it comes to specifying the schema of an object. I'm seeing all
three of the following syntaxes in use:
"schema": "/some/url"
"schema": {"$ref": "/some/url"}
"$schema": "/some/url"
So which is it to be? :)
"schema": {"$ref": "/some/url"}I'm also a bit concerned about how the JSON referencing standard is specified and the way this is intertwined with the self-describing spec for json-schema. For example I notice that the http://json-schema.org/json-schema metaschema is an instance of http://json-schema.org/hyper-schema, which in turn extends http://json-schema.org/json-ref. But this would only give a schema-specified meaning to the use of json referencing properties on the top-level object (as I understand it), and not specify its meaning when used in arbitrary nested positions (which it is used at in the meta-schemas).
"additionalProperties": {"$ref": "#"}
Which makes it recursively applicable to all nested objects.
I think this is logically/mathematically consistent. However,
I understand that practically, specifying how to interpret oneself
makes life difficult for bootstrapping implementations.Another alternate approach that could be considered is rather than using JSON referencing, defining each of the properties in JSON Schema that might take references as (possible) link relations themselves (and defining properties as something that should only be interpreted as a link if the value is a string). The intent would be that a linking schema might look like:
{
"extends":"some/url",
"properties":{
"foo":"another/url",
....
Presumably we would need to define strings to be interpreted as links for "extends", "schema", "type", "items", "additionalProperties", and any property definition value.
This wouldn't really eliminate the meta-circular nature of meta-schemas (I think if properly spec'ed, issues with handling this should be mitigated, and then meta-circular self-definition is actually a nice property), but it would make links in schemas somewhat less abstract (and more compact). The drawback is that it this might be actually be a little more difficult to interpret since there a wider range of properties that can understood as links.
I'm open to any thoughts on this...
-- Thanks, Kris
Matthew W
>
> "schema": {"$ref": "/some/url"}
OK. In that case the following in http://json-schema.org/hyper-schema
should probably change? from:
"schema":"#"
to
"schema": {"$ref": "#"}
And I'm not sure what the implications are for this:
{
"href": "{$schema}",
"link": "definedby"
}
since presumably you wouldn't want to have to supply both a "schema":
{"$ref": "foo"} and a "$schema": "foo". But the former might not
always use a json reference so you couldn't rely on, say, "{schema.
$ref}" always giving a link relation for definedby.
> If you can swallow the meta-circular nature, the last line of http://json-schema.org/json-ref defines itself as the schema for all its
> property values:
>
> "additionalProperties": {"$ref": "#"}
>
> Which makes it recursively applicable to all nested objects.
Ah neat! apologies I missed this. That addresses my concern about use
for nested objects then, I think. Although:
* Is there a way to extend json-ref from a tuple schema which is an
array of schemas? presumably i'd have to make each schema in the array
in turn extend json-ref. Maybe another point against the idea of tuple
schema as an array of schemas vs using a schema object of type tuple?
* Does the recursiveness of the json-ref schema also work when you get
nesting that involves arrays, or just for object-property nesting?
* Seems the json-ref schema needs eg "schema": {"$ref": "http://json-
schema.org/hyper-schema"} adding to it to make it clear that it is an
instance of hyper-schema and hence of itself, hence allowing the use
of a json reference inside the schema for json references? (my head's
starting to spin a little :)
I have to admit though I still have a weird nagging feeling about the
correctness of this metacircular stuff. Because the default is to
allow arbitrary additionalProperties, I wonder if some of the
metacircular schema structure might be validating just via this
catchall rather than via the intended structured schema elements. Have
you tried validating strict-ified version of the metaschemas with
additionalProperties: false specified for most objects, in order to
make sure they're specifying themselves fully?
(I guess this highlights a bit of a general problem/tradeoff with the
schema extension mechanism - additionalProperties: false makes it hard
to extend the schema with new properties, but additionalProperties: {}
makes it hard to achieve the desired level of validation strictness.
But at least doing a validation of the metaschemas against strictified
versions of themselves would give confidence in the correctness of the
non-strict versions)
I do like the fact that there is a metacircular schema for this stuff
though. I'm in no means opposed to it, just wanted to convince myself
firmly that it's all logically correct :)
> I definitely agree with your concerns, and at the very least the
> referencing/linking mechanism supported in the schemas should be
> explicitly spelled out rather than relying on meta-circular meta-schema
> definitions from json-schema.org. I would prefer not to have a separate
> JSON-ref spec that JSON schema relies on, since part of the idea is that
> JSON-ref can be defined by JSON schema.
Yep. I think with the current approach, if the metacircular stuff is
all indeed correct, you still need to do more to specify the semantics
of how the link relations defined by json-ref are to be interpreted
when a reference object is encountered in a schema (and indeed in
general, but in particular for defining the semantics of references
found in the metaschemas)
> Another alternate approach that could be considered is rather than using
> JSON referencing, defining each of the properties in JSON Schema that
> might take references as (possible) link relations themselves (and
> defining properties as something that should only be interpreted as a
> link if the value is a string). The intent would be that a linking
> schema might look like:
> {
> "extends":"some/url",
> "properties":{
> "foo":"another/url",
> ....
> Presumably we would need to define strings to be interpreted as links
> for "extends", "schema", "type", "items", "additionalProperties", and
> any property definition value.
I do like this actually. For my application we're probably not going
to be using json-ref to do clever object-graph references within
individual json files, or any relative URI addressing for that matter.
Rather using id properties or the full uris defined by that 'self' /
'full' link relations to establish object identity, and using this
object identity to resolve cross-references / cyclic references in the
json tree.
So for that reason I'd prefer not to need to depend on json-ref to do
schema stuff, just depend on the hyper-schema link relation stuff
possibly with a special identity interpretation of the 'self'
relation.
Or maybe if the schemas allowed you to specify a list of properties to
be used as a kind of 'primary key' or identity key for an object. Then
the cross-references/cyclic-references could be resolved using this
defined notion of equality. That seems potentially even nicer.
> I'm open to any thoughts on this...
Good to hear. Hope you don't mind me thinking aloud about this
stuff :)
-Matt
Ganesh and Sashi Prasad
Regards,
Ganesh
--
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.
Matthew W
> you tried validating strict-ified version of the metaschemas with
> additionalProperties: false specified for most objects, in order to
> make sure they're specifying themselves fully?
On second thoughts, I can see this isn't going to work because of the
way metaschemas use 'extends' and the semantics of extends.
Perhaps a better suggestion for now would be to have an optional flag
which can be passed to the validator which enables warnings or
validation failures whenever something in encountered which validates
only via the default value for additionalProperties, ie the catch-all
schema {}.
(If a schema goes out of its way to explicitly specify
"additionalProperties": {}, maybe that wouldn't flag the warning/
error). Anyone know if any existing validators implement anything like
this?
With this feature, you could then validate the metaschemas against
themselves with this flag turned on for extra confidence.
In general, typically what I would want when it comes to
additionalProperties, would be the ability to specify something like
"additionalProperties":
"only_where_specified_in_some_extension_schema_and_when_validating_in_the_context_of_that_schema"
(!) as an alternative to false, or to some other schema.
This might complicate the semantics of 'extends' a bit (which as I
understand it at present is simply a boolean AND operation, ie
conforms to this schema AND to this additional schema too) although I
tried to phrase it in a way which is sort-of-consistent with this.
-Matt
Matthew W
Sorry to give you such a barrage of issues, but I think I've spotted
another problem with having schemas extend the json-ref schema as a
general-purpose way of allowing (and specifying the semantics of)
arbitrary nested usage of json referencing.
The current approach happens to work fine for the purposes of your
metaschemas, because all the properties of the schema objects happen
to be optional, so a {"$ref": "/look/elsewhere"} object is always
going to be acceptable.
But say I have a schema for a json document where some of the objects
have non-optional properties, and I want to be able to use json
references in place of those objects.
The {"$ref": "/look/elsewhere"} object then isn't going to validate,
even if the schema extends the json-ref schema, because some non-
optional property is required in that context and instead it's only
going to see the $ref property. This seems strong evidence to me that
the substitution of these json references is a lower-level concern
than should be done in a first pass before the resulting object graph
is validated against a schema. (Or maybe that the dependency of the
json-schema on json-ref should be removed or reduced as discussed in
other emails)
Cheers (and apologies if again I failed to notice a feature of the
schemas that works around this)...
-Matt