*** Format 1 - Schemas-Can-$ref-Link
If a schema specifies a "$ref" attribute, it should be replaced with
the JSON that has the provided URI.
For example, this is how a schema would use this format for
referencing:
{
"id":"my-card",
"name":"A schema that extends card",
"extends":{"$ref":"http://json-schema.org/card"}
"properties":{
"another-card":{"$ref":"my-card"}
}
}
Advantages:
-Backwards compatable with previous drafts, and compatable with json-
ref.
-If defined in the core schema, it is forward compatable with hyper
schema.
Disadvantages:
-Requires extra characters/noise in the schema.
[...]
> "$extends":"http://json-schema.org/card",
but I think my prefered solution is the first one:
>> "extends":{"$ref":"http://json-schema.org/card"}
And, sorry for this intrusion, but I'd like to be able to reference an embeded piece of schema with RUL like:
>> "extends":{"$ref":"#schemas.card"}
where the format after the # would be JSON Path like
Note that I may have missed the possibility from another way
> --
> 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.
>
The $ref syntax makes it clear that the value is a link, that baseURI
applies, etc.
I've come to appreciate the $ref syntax, 'format 1' gets my +1.
Chris
>
> Thank you all!
On 11/4/2010 5:49 AM, Andi wrote:
> +1 to 1)
>
> The current way of referencing is good enough, because
>
> 1) It is a standard and implemented in some frameworks like dojo.
I'm core committer for Dojo, so it wouldn't be hard to get Dojo updated.
> 2) You can unambiguously reference normal values, not only schemas.
Note that we aren't getting rid of JSON referencing as a possible
referencing mechanism, we just are using it in schemas for the
properties that take schemas. I am not aware of any of these properties
that would take a "normal" value except type and requires. Why would you
create a URL to reference "number", when it is actually shorter to
actually type it?
> 3) It is more readable. The author will instantly recognize that it is
> a ref.
>
> Doing
>
> {
> type:"integer",
> title:"otherSchema.title"
> }
>
Title can't reference a schema, so this wouldn't accept URLs. The
"title" attribute wouldn't introduce any ambiguity.
--
Thanks,
Kris
What about the current draft then? It says that you can use URIs
(which includes ids as far as I understand it) instead of schemas. I
think this should be removed.
I either want to be able to reference all properties with $ref OR
being able to reference all properties with a string, which is
ambiguous.
I think it's better to have one clear solution for referencing. In
this case the draft must be changed.
+1 from me as well, the syntax overhead is small, it can hardly be construed a big pain.
--
Robin Berjon
Robineko (http://robineko.com/)
I vote for 1. The project with which I am involved makes use of Json
Schemas for complex Json structures. An idiom we use frequently (I'm
not even sure if it complies with
the Json schema spec, we use our own validator) goes like this
(omitting quotes)
properties : {
interval : {$ref : "RelativeTimeInterval", optional:true}
}
..in other words, referencing an existing schema and overriding a
schema attribute. I don't see how we can do this if the schema
reference is a simple string uri
Based on your question, I imagine you're writing a validator that will
load a relative file if referenced. Unless you're going to enforce the
condition above, I would recommend checking your internal cache of
schemas first before loading a file. (Faster and probably what the
author is intending)
Other validators (such as JSV) don't load referenced files as it
treats URIs as identifiers and not locations. (Hence URIs, not URLs)
-Gary
Thanks a lot for your response. I've re-read the id part of the spec
and your explanation makes total sense.
Cheers
I notice that the core schema (http://json-schema.org/schema) doesn't
specify additionalProperties for schemas themselves (as far as I can
tell). I assume then that the default (empty) schema applies for
additionalProperties for schemas themselves, and hence a schema may
have additional properties of any type e.g.
{
"id":"my-card",
"name":"A schema that extends card",
"extends":{"$ref":"http://json-schema.org/card"}
"properties":{
"another-card":{"$ref":"my-card"}
}
"myextraproperty":"myextravalue"
}
Is my understanding correct?
Cheers
On 10 January 2011 21:35, Gary Court <gary....@gmail.com> wrote:
-Gary