sample

[Eric Stob]

Hi guys,

I am looking for a good fully featured sample json schema so I can
know how to use it.

I understand the basics but I don't understand how to use things like
extends and id and name and $ref.

does anyone have a good example that uses all the featrures of json
schema the way they are supposed to be used?

and also how to deal with naming collisions, I have two files that
each have a schema with the same name.

Thanks!
Eric

[Xample]

id will name a node in a schema

{
"id":"#uniqueSchemaID",
"description":"this is an empty schema with only an id and this
description"
}

the reference to a schema, i.e. all the content of this schema will be
replace by the schema above

{
"$ref":"#uniqueSchemaID"
}

will then be considered as:
{
"id":"#uniqueSchemaID",
"description":"this is an empty schema with only an id and this
description"
}

i.e. all the content of the subschema #uniqueSchemaID will override
the schema $ref erring it

The "extends" keyword is to be considered as an include… the schema
extending one or many schemas will then validate a document through
all of the schemas.

exemple:

{
"type":"number",
"maximum":10,
"extends":{"minimum":"0"}
}

is "equivalent" to

{
"type":"number",
"maximum":10,
"minimum":"0"
}

The "name" is (as title and description) only a metadata property,
basically used in order to name what does represents the schema.

For more information about the references, please take a look on the
forum, I posted many relevant examples.

Best regards

[Eric Stob]

Thank you Xample that was very helpful information!

Is ID completely free form? Does it always start with pound sign? Contain dots or slashes? Should it include namespace? Company / project name?

I will try to find your other examples tomorrow.

But in addition to these types of academic examples, I was hoping that perhaps someone has used all the features in a real world case and would be willing to share their work as an example of a fleshed out schema that ties it all together?

Thank you!
Eric

> --
> 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 Fri, May 11, 2012 at 10:11 AM, Eric Stob <eric...@blekko.com> wrote:
[...]

>
> Is ID completely free form? Does it always start with pound sign? Contain dots or slashes? Should it include namespace? Company / project name?
>

That is actually a difficult question. The spec (draft v3) says:

----
This attribute defines the current URI of this schema (this attribute
is effectively a "self" link). This URI MAY be relative or absolute.
If the URI is relative it is resolved against the current URI of the
parent schema it is contained in. If this schema is not contained in
any parent schema, the current URI of the parent schema is held to be
the URI under which this schema was addressed. If id is missing, the
current URI of a schema is defined to be that of the parent schema.
The current URI of the schema is also used to construct relative
references such as for $ref.
----

This is not very clear, to say the least. In theory, id can be
anything, but some values just don't make any sense. Consider:

As a rule of thumb:

* limit yourself to hash values (ie, fragments as per the URI spec --
which mean they MUST be URI encoded should a reserved character be
present) for "id",
* EXCEPT for a "parent-less" schema, ie a root schema, where you
should, ideally, have an absolute URI (a non absolute URI doesn't make
any sense anyway at this particular position) WITHOUT a fragment part,
or an empty one (again, this doesn't make any sense and conflicts with
JSON Reference).

Also, you may use JSON Pointer to address subschemas. Example:

{
// whatever
"x": {
"id": "#myschema"
}
// whatever
}

If, within this schema, you want to address the subschema, you may
write a JSON Reference using either:

{
"$ref": "#myschema"
}

or (JSON Pointer):

{
"$ref": "#/x"
}

Also note that nothing in the spec forbids duplicate ID entries within
the same schema (which is a mistake imo). JSON Pointers, on the other
hand, are unambiguous, you have no two ways of referring a part of a
JSON instance.

That is only part of the story...

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

[Francis Galiegue]

On Fri, May 11, 2012 at 10:50 AM, Francis Galiegue <fgal...@gmail.com> wrote:
[...]

>
> This is not very clear, to say the least. In theory, id can be
> anything, but some values just don't make any sense. Consider:
>

Sorry, I meant to introduce examples here, but got carried away.

Imagine a "root-less" schema, ie a schema with no absolute URI or a
made-up URI, and this in the schema:

{
"id": "a/b/c"
}

That is just impossible to lookup. Don't do that.