The current state of schema addressing is awkward at the very best.
For instance, the current hyperschema proposal has:
----
{
"$schema" : "http://json-schema.org/draft-04/schema#",
"id" : "http://json-schema.org/draft-04/schema#",
"type" : "object",
"properties" : {
"type" : {
"type" : [
{
"id" : "#simple-type",
[...]
----
OK, now the question: how do you address #/properties/type/type/0 from
the outside with its embedded id? Why are ids in subschemas allowed at
all? What is their purpose? How come ids which are themselves
fragments are allowed at all?
If it were only me:
* a schema ID cannot have a fragment part other than #,
* IDs in subschemas should be forbidden, and JSON Pointer used for
addressing inner schemas.
This would make things clear. Consider the example above: how do you
address subschemas of #simpletype? Answer: you can't. Whereas with my
proposal, you can.
--
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)