View this page "Json Schema Proposal Working Draft"

[Kris Zyp]

Updates are now being made on this working draft, and the "second
draft" will be frozen.

Click on http://groups.google.com/group/json-schema/web/json-schema-proposal-working-draft
- or copy & paste it into your browser's address bar if that doesn't
work.

[Steve Vinoski]

Hi Kris, thanks for the "identity" vs. "id" clarification. It helps,
especially the link to the "schema for schemas," but there are some
typos in the "identity" description that make it a little awkward.
Perhaps you could consider replacing the description for "identity"
with the following?

* identity
This indicates that the instance property can be used to uniquely
identify the instance. It is false by default. A property that has its
identity property set to true should be unique for all instances of
this schema. It is not necessary to validate the identity property.
Most validators may only validate a single instance object at a time
and therefore cannot determine whether other instances have unique
values. This property is informative, indicating which property can be
used to identify an object from a data store. An identity property may
correspond to a database key column.

[Kris Zyp]

This sounds excellent, I will update the working draft. Let me know if you
have another wording improvements you'd like.
Thanks,
Kris

[John Calcote]

Hi - It's not clear to me from this specification how one would go
about describing internal references. For the schema that I'm
currently working on, I'm simply using the external reference format
described in the proposal, but it's not really clear that this is the
appropriate thing to do. For a concept as important as sub-schema
referencing, I should think that the specific syntax would be
explained in greater detail. Sub-schema referencing is critical to
reduce redundancy in larger more complex schemas, wouldn't you agree?

Example (admittedly contrived):
[
{ "id":"book",
"type":"object",
"properties":{"title":"string", "author":"string",
"isbn":"string"}
},
{ "description":"library",
"type":"object",
"properties":{"Books":{type":"book"}
}
]

--john

[Jacob]

John,

The example (included below) in the draft under Extending and
Referencing demonstrated how to reference as you are talking about
with marriedperson.spouse. Is this what you are looking for?

Jacob
{

"id":"person",

"type":"object",

"properties":{

"name":{"type":"string"},

"age":{"type":"integer"}

}

}

Which can be extended:
{"id":"marriedperson",

"extends":{"$ref":"person"},

"properties":{

"age":{"type":"integer",

"minimum":17},

"spouse":{"$ref":"marriedperson"}

[Kris Zyp]

John Calcote wrote:
> Hi - It's not clear to me from this specification how one would go
> about describing internal references. For the schema that I'm
> currently working on, I'm simply using the external reference format
> described in the proposal, but it's not really clear that this is the
> appropriate thing to do. For a concept as important as sub-schema
> referencing, I should think that the specific syntax would be
> explained in greater detail. Sub-schema referencing is critical to
> reduce redundancy in larger more complex schemas, wouldn't you agree?
>
>

I agree, you are correct. More examples/explanation should be included.

> Example (admittedly contrived):
> [
> { "id":"book",
> "type":"object",
> "properties":{"title":"string", "author":"string",
> "isbn":"string"}
> },
> { "description":"library",
> "type":"object",
> "properties":{"Books":{type":"book"}
> }
> ]
>

You have the right idea, I think your second schema would look like:

{ "description":"library",
"type":"object",
"properties":{
"Books":{

"items":{"$ref":"book"}
}
}
}

And I assuming here that you actually want the Books property in the
library objects to be an array, where each item in the array is a book
(hence the reference to the book schema). Anyway, I will try to get at
least another example on the specification page.
Thanks,
Kris

> --john
> >
>

[John Calcote]

Jacob: I saw that example, and studied it in detail, but this is an
example of extending an existing schema, rather than one of simple
referencing it for use as a sub-schema in multiple places in the main
or root schema object. In XML Schema, this is all very complex, of
course, and JSON schema makes it simpler, but the syntax must still
exist to reference the schema of a subordinate object within the
description of a greater super-structure. Simply put, I can't figure
out the syntax for simply using an object described in the same schema
as another object. Extension is more complex than I need. Thanks for
the input, though. John

[John Calcote]

Kris, Thanks, this is exactly what I was looking for. --john

[Bruno Prieto Reis]

Kris,

there is a missing comma and an extra ] on the more schema example on
the working draft, the following is coorect, and validates ok too:


{
"description": "A person",
"type": "object",
"properties": {
"name": {
"type": "string"
},
"born" : {
"type": [
"integer",
"string"
],
"minimum": 1900,
"maximum": 2010,
"format": "date-time",
"optional": true
} ,
"gender" : {
"type": "string",
"enum": [
"male",
"female"
],
"options": [
{
"value": "male",
"label": "Guy"
},
{
"value": "female",
"label": "Gal"
}
]
},
"address" : {
"type": "object",
"properties": {
"street": {
"type": "string"
},
"city": {
"type": "string"
},
"state": {
"type": "string"

[Bruno Reis]

In this one (Self-Defined Schema Convention ) there was a missing comma just before the "name" either. The code below is correct:
{
    "$schema": {

        "properties": {
            "name": {
                "type": "string"
            },

            "age" : {
                "type": "integer",
                "maximum": 125,
                "optional": true
            }
        }
    },
    "name" : "John Doe",
    "age" : 30,
    "type" : "object"
}

2008/12/8 Bruno Prieto Reis <bruno....@gmail.com>

[Fred]

Hi Guys,

I'm interested in using JSON to define some data structures that I
will be passing over a serial connection. The definitions will be hand
written and static with respect to the release version of the project.
Because they are hand written I'd like to provide schemas and use them
myself to check my work before releasing.

I have a couple of questions.

1) There seem to be other json schemas, how can I be certain that this
one is the one that will be standardised?
2) The specification is (to me) unclear with respect array
definitions. I'd love to see some different examples of array schema
definitions in the guide/spec.
3) At a quick glance I couldn't see a way of describing repeating
elements, is this possible or even desirable to do? Or should I just
use arrays as I have currently drafted?

My particular use is to have sets of data structures of the same type/
structure in arrays or repeating elements. I'd like to be certain that
I'm not "doing it wrong!" :-)

I'd be happy to start another thread and give examples for critique if
that is a more appropriate way to discuss some of this.

Cheers,

Fred.

[Kris Zyp]

Fred wrote:
> Hi Guys,
>
> I'm interested in using JSON to define some data structures that I
> will be passing over a serial connection. The definitions will be hand
> written and static with respect to the release version of the project.
> Because they are hand written I'd like to provide schemas and use them
> myself to check my work before releasing.
>
> I have a couple of questions.
>
> 1) There seem to be other json schemas, how can I be certain that this
> one is the one that will be standardised?
>

I was not aware of any competitors (nor is my google search results for
"JSON Schema"). There are a few other schema languages that can be used
to validate JSON (like Cerny and Kwalify, which is cited in the spec),
but that aren't JSON-based, they written in other languages. I did a the
search for a JSON schema and basically all the top results (except for
the non-JSON based exceptions) seem to point back to this proposal. Do
you have any particular alternative in mind?

> 2) The specification is (to me) unclear with respect array
> definitions. I'd love to see some different examples of array schema
> definitions in the guide/spec.
>

Good suggestion, I added another short example in the working draft page
(search for hobbies).

> 3) At a quick glance I couldn't see a way of describing repeating
> elements, is this possible or even desirable to do? Or should I just
> use arrays as I have currently drafted?
>

Repeating elements are described with arrays in JSON, and JSON Schema
doesn't attempt to contradict that.
Thanks,
Kris

[Fred]

Hi, thanks for the response :-)

> > 1) There seem to be other json schemas, how can I be certain that this
> > one is the one that will be standardised?
>
> I was not aware of any competitors (nor is my google search results for

<snip>

> you have any particular alternative in mind?

This was what prompted me to ask :

http://www.kruse-net.dk/json-schema/

> Good suggestion, I added another short example in the working draft page
> (search for hobbies).

Thank you!

> Repeating elements are described with arrays in JSON, and JSON Schema
> doesn't attempt to contradict that.

Thanks again!

Further question, is there a live version of THIS validator on the
web?

Regards,

Fred.

[Kris Zyp]

Fred wrote:
> Hi, thanks for the response :-)
>
>
>>> 1) There seem to be other json schemas, how can I be certain that this
>>> one is the one that will be standardised?
>>>
>> I was not aware of any competitors (nor is my google search results for
>>
> <snip>
>
>> you have any particular alternative in mind?
>>
>
> This was what prompted me to ask :
>
> http://www.kruse-net.dk/json-schema/
>

Jakob actually discussed this on this discussion group and I believe we
incorporated some of his suggestions in this proposal, if i recall. It
appears that his comments are on an older version of JSON schema and
were fixed, thus it actually became part of the evolution of the current
proposal.

Kris

[Fred]

Awesome, that is what I wanted to hear, best I get on with using it
then :-)

Thanks!

Fred.

ps, is there somewhere valid to whinge about the lack of comments in
JSON ? Extremely short sighted move that one IMO.

[Kris Zyp]

Bruno, do you have a publicly available instance of your validator? It
would probably the best and easiest to use a "live" version of the
validator.
Kris

[Bruno Reis]

Unfortunatly no.

I have a lot of work to do here because we are forming a development team, defining architectrure, process, etc, for a new project, so I won´t be able to think about it so soon. But any of you are more than welcome to publish one if you like to. I would be very happy with this.

By the way, I beleive either that most of that issues on the other validator site are already adressed. At least most of them made no sense to me when I read. : )

2008/12/18 Kris Zyp <kri...@gmail.com>

[Jakob Kruse]

Hi everyone

Kris is correct. My schema proposal was made before I was aware of
Kris' efforts in this group. The proposal at http://www.kruse-net.dk/json-schema/
is in use by me and a couple others for format descriptions and
validation (a friend of mine wrote a validator for it), and is thus
not going to disappear anytime soon, but the goal is to develop both
my own proposal and the proposal in this group in a direction such
that they will eventually merge into one. As Kris said, some of that
has already happened. I have been away for a while and busy with
others things, but as soon as I get the time I will have a look at the
current state of the two proposals and update my page.

/Jakob

[Fred]

> others things, but as soon as I get the time I will have a look at the
> current state of the two proposals and update my page.

That is exactly what is needed, good on you!

Fred.

[sieh...@googlemail.com]

The "id" and the "$ref" property are not contained in the list of
allowed schema attributes. Can you please add them to get a complete
list?

[Kris Zyp]

These are defined by the Hyper-Schema proposal:
http://www.json.com/specifications/hyper-schema/
This is effectively provides an extension to JSON schema for defining a
referencing mechanism (which defaults to the JSON referencing
convention), and provides a meta-circular definition that can then be
utilized for the self-descriptive JSON schema for schemas.

The hyper-schema proposal is certainly newer, and could use some more
thorough review/discussion. One point worth considering; perhaps the
separation of hyper-schema from json-schema is confusing and these
definitions should be rolled into json schema. However, keeping json
schema itself as simple as possible was the primary motivation here.

Also worth noting that the list of schema attributes is a not
constrained list of "allowed" attributes. JSON schema allows any
property on schemas, it just defines the correct constraint and meaning
of a certain list of properties, but others can be used as well (like
"id" and "$ref"). The important issue here is defining the
interpretation of "$ref" and "id", which is the purpose of hyper-schema.

Kris

[Seth]

I'm confused as to which JSON Schema proposal is the prevalent one.
The proposal at http://json-schema.org/ is slightly different than the
one here. It contains an unconstrained property (and perhaps other
differences that I'm not aware of). Which of these proposals should I
be following?

Thanks

On Jun 8, 8:51 pm, Kris Zyp <kris...@gmail.com> wrote:
> These are defined by the Hyper-Schema proposal:http://www.json.com/specifications/hyper-schema/
> This is effectively provides an extension to JSON schema for defining a
> referencing mechanism (which defaults to the JSON referencing
> convention), and provides a meta-circular definition that can then be
> utilized for the self-descriptive JSON schema for schemas.
>
> The hyper-schema proposal is certainly newer, and could use some more
> thorough review/discussion. One point worth considering; perhaps the
> separation of hyper-schema from json-schema is confusing and these
> definitions should be rolled into json schema. However, keeping json
> schema itself as simple as possible was the primary motivation here.
>
> Also worth noting that the list of schema attributes is a not
> constrained list of "allowed" attributes. JSON schema allows any
> property on schemas, it just defines the correct constraint and meaning
> of a certain list of properties, but others can be used as well (like
> "id" and "$ref"). The important issue here is defining the
> interpretation of "$ref" and "id", which is the purpose of hyper-schema.
>
> Kris
>

[Kris Zyp]

I try to keep them in sync... Thanks for the heads up, I just removed
"unconstrained" from the proposal at json-schema.org (it is not
necessary now that there is "enum" and "options").
Kris

[Seth]

Awesome, thanks very much!

On Aug 4, 3:11 pm, Kris Zyp <kris...@gmail.com> wrote:
> I try to keep them in sync... Thanks for the heads up, I just removed
> "unconstrained" from the proposal at json-schema.org (it is not
> necessary now that there is "enum" and "options").
> Kris
>
> Seth wrote:
> > I'm confused as to which JSON Schema proposal is the prevalent one.

> > The proposal athttp://json-schema.org/is slightly different than the

[mickey ristroph]

There are two typos in one of your example schemas on json-schema.org:
A missing " for a key name, and a spurious ] in the middle of the
properties object.

Original, lines with errors starred ***:

{"description":"A person",

"type":"object",

"properties": {
"name": {"type":"string"},
"born" : {"type":["integer","string"],
"minimum":1900,
"maximum":2010,

"format":"date-time",
"optional":true}

*** ],
"gender" : {"type":"string",
"options":[

*** {"value:"male","label":"Guy"},

{"value":"female","label":"Gal"}]},
"address" : {"type":"object",
"properties":{

"street":{"type":"string"},
"city":{"type":"string"},
"state":{"type":"string"}
}
}

}
}

The corrected version, now valid JSON:

{

"description": "A person",
"type": "object",
"properties": {
"name": {
"type": "string"
},
"born" : {
"type": [
"integer",
"string"
],
"minimum": 1900,
"maximum": 2010,
"format": "date-time",
"optional": true
} ,
"gender" : {
"type": "string",

[rmorant]

What about property order?
I think that may be important, for example if we want to create a Form
from a JSON schema.
What do you think?

[Marak Squires]

Wouldn't the property order be dictated by the order you listed the properties? 

[Seth Wessitsh]

The problem I see with just using JSON document order is that AFAIK the JSON specification says that objects are un-ordered key/value pairs.  So even though Javascript (at least the implementations I've used) retains the property order when creating an object from the JSON document not all implementations are required to do so.


Seth C. Wessitsh
se...@wessitsh.com

[rmorant]

I found the properties unordered problem while code a REST service
than get the schema, modify it and returns the newest to the client
that use it to render a Form. I use java libraries (server) and
javascript (client) and the properties order change.
I think the specification should define this behavior and not the
implementation, don't you?

[Kris Zyp]

The specification (at json.org) does define this behavior, JSON objects
are specifically defined to be unordered name/value pairs. One shouldn't
expect ordering from implementations (even if they go above and beyond
their call of duty). Defining order for the purpose of form generation
would be a visual suggestion aspect of a schema. I think it would be
great to see a spec/meta-schema created for defining visual indicators
within schema for form generation. Actually some attributes of the core
schema definition might be better placed in a visual meta-schema like
"options", "title".
Kris

[Hatem Nassrat]

On Wed, Sep 09, 2009 at 08:27:41AM -0600, Kris Zyp wrote:
> The specification (at json.org) does define this behavior, JSON objects
> are specifically defined to be unordered name/value pairs. One shouldn't
> expect ordering from implementations (even if they go above and beyond
> their call of duty). Defining order for the purpose of form generation
> would be a visual suggestion aspect of a schema. I think it would be
> great to see a spec/meta-schema created for defining visual indicators
> within schema for form generation. Actually some attributes of the core
> schema definition might be better placed in a visual meta-schema like
> "options", "title".

I think the idea of having a specific order is not just specific to form
generation. Yes, this is a usecase, but i think having an specific order
has more benifits. One of the main things that attract me to JSON is the
compact readable syntax, being able to print out a JSON document and
know exactly where to find things is a nice feature. However, this is
lost if the order is not gauranteed.

I disagree that the order should not be preserved by default. It feels
that the reason for this is that many languages implement an object as
an unordered hash map. I do not think JSON nor JSON Schema should be
concerned with how the object is implemented internally, but should be
more concerned on the usage of both documents (Schema and Conforming
Document).

IMHO, i think the order should be preserved by default and having an
option to say order is not important. It could also be the other way
around, but for the reason mentioned above I think order is something
important.

--
Hatem Nassrat

PS. I posted an EBNF like schema that I have used to document a set of
JSON documents. As a specification in that schema was that order must be
preserved. Moreover, the simplest validating parser of that schema would
require things to appear in the right order (this is just a bonus, again
as I mentioned, this shouldn't be the reason to do things one way or the
other).

[Alexandre Morgaut (snow)]

If an order is required, JavaScript and JSON has the array

you can always convert :

{
"field1": "123",
"field2": "foo",
"field3": "bar"
}

which is unordered by

[
{"field1": "123"},
{"field2": "foo"},
{"field3": "bar"}
]

its not really more complicated, and its ordered

an easier to use format would still then be

[
{"name:"field1","value": "123"},
{"name:"field2","value": "foo"},
{"name:"field3","value": "bar"}
]

[Hatem Nassrat]

On Wed, Sep 09, 2009 at 06:03:09PM +0200, Alexandre Morgaut (snow) wrote:
>
> If an order is required, JavaScript and JSON has the array
>
> you can always convert :
>
> {
> "field1": "123",
> "field2": "foo",
> "field3": "bar"
> }
>
> which is unordered by
>
> [
> {"field1": "123"},
> {"field2": "foo"},
> {"field3": "bar"}
> ]

I think you have missed what I was trying to say. JSON is a data
representation, making the JSON object be specified as an unordered set
of key value pairs makes it resemble the data structure which implements
it. IMHO data representation should not be coupled to the way the data
would be implicitly stored (when it is no longer in a JSON document).

To reiterate, the JSON document itself is an ASCII (or some encoding)
file, the charachters in the file will not jumble themselves. However,
the specification means that programs may put key value pairs of a JSON
object into a JSON document with arbitrary order, although this gives
the system the flexibility to use an unordered hash map to represent a
JSON object it doesn't make much sense to impose such a data structure
on all JSON users (whether human or software).

For the purpose of human readability my argument is the order makes it
easy to locate the data being represented by the JSON data
representation.

--
Hatem Nassrat

PS. JSON should not be 1-1 mapped to JavaScript even if it has it in the
name. Moreover, JSON objects are not 1-1 mapped to JavaScript Objects
(e.g. you do not need to quote (even double quote) your keys with
JavaScript).

[rmorant]

Ok, i'm agree with you, but in that case, what about label property in
options definition. should be in the new spec/meta-schema?. And
"hidden", why for?
Any way i think will be useful a property or directive that defines/
proposes the order that the json serialization application should
respect in order to be more human friendly.
And incidentally serve to user interfaces.

[Tatu Saloranta]

On Fri, Sep 11, 2009 at 9:28 AM, rmorant <rmor...@gmail.com> wrote:
>
> Ok, i'm agree with you, but in that case, what about label property in
> options definition. should be in the new spec/meta-schema?. And
> "hidden", why for?
> Any way i think will be useful a property or directive that defines/
> proposes the order that the json serialization application should
> respect in order to be more human friendly.
> And incidentally serve to user interfaces.

Schemas generally define logical content and data model, but less
often "cosmetic" aspects, such as optimal configuration for display on
GUIs (or details of serialization process). And given that JSON data
model itself explicitly states that there is no implied logical
ordering for object fields (just physical one, which is arbitrary,
conceptually), it really does not seem like this would be an ideal
thing to include.

But perhaps there could be section(s) of additional optional related
data, within schema specification.

-+ Tatu +-

[vice]

I think the instance with self-defined schema is incorrect.
"type": "object must be inside the $schema object and corrected minor
comas errors.

result:

{
"$schema":
{ "type" : "object",

"properties":{
"name": {"type":"string"},

"age" : {"type":"integer",
"maximum":125,
"optional":true}
}
},
"name" : "John Doe",
"age" : 30
}

Sorry, I forget to insert one coma to this correction.

[vice]

I think the instance with self-defined schema is incorrect.
"type": "object must be inside the $schema object and corrected minor
comas errors.

result:

{
"$schema":
{ "type" : "object",
"properties":{
"name": {"type":"string"},
"age" : {"type":"integer",
"maximum":125,
"optional":true}
}
}

[Eric W.]

Thank you for the very useful standard.

In the schema for the "more sophisticated" example, above, there is a
missing quotation mark:

{"value:"male","label":"Guy"},

should be:

[Kris Zyp]

Put a notice pointing to the Internet Draft for the latest
specification.

Click on http://groups.google.com/group/json-schema/web/json-schema-proposal-working-draft?hl=en_US
- or copy & paste it into your browser's address bar if that doesn't
work.

[Petri Lehtinen]

Neither the specification or the core meta-schema state what's the
default value for minimumCanEqual and maximumCanEqual. It would feel
natural that they are true by default, and only effective if minimum/
maximum is also used, but this is not explicitly stated.

Petri

[Kris Zyp]

This should be clarified. Currently all boolean schema attributes
default to false (and have been worded such that the false value is the
most reasonable default). I wonder if we should change these to
minimumCantEqual and maximumCantEqual (or something else) to preserve
this consistency, if we feel that would be the most reasonable.

Kris

--
Thanks,
Kris

[Petri Lehtinen]

Kris Zyp wrote:
> This should be clarified. Currently all boolean schema attributes
> default to false (and have been worded such that the false value is the
> most reasonable default). I wonder if we should change these to
> minimumCantEqual and maximumCantEqual (or something else) to preserve
> this consistency, if we feel that would be the most reasonable.

I don't see any other properties than "optional" in the core schema
definition that are boolean. It is false by default, which is
intuitive, but I don't think that one property is enough to set a
standard that the "minimumCanEqual" and "maximumCanEqual" need to be
consistent with.

Petri

[dme...@msn.com]

Question: How to you use the "requires" property when you want to
enforce another property to not only be present, but have a particular
value. For example, in the "state/town" example (in the
documentation) - how could you specify that 'town' could be there only
if 'state' was, and the value of 'state' had to equal "New York"?

[Jack Vinijtrongjit]

Why would you need keep them in specific order if you access them using XPath-like function or normal dot-notation in JavaScript? Don't you just traverse down your data and find matching definition in the schema? Then for required elements in the schema, you can then do a reverse check during the second pass?

In XML, you typically specify the order in the XSD using Sequence tag. It's actually convenient if you expect certain application down the line to actually read traverse the data blindly. There are many XSDs that I have encountered that have (and don't have) specified sequence and with a good validator, there isn't really an issue. If you XSD generator in the other hand create XSD with different order and slap a Sequence tag on top like some IBM tools do, that's a different story.

I don't see how the validator (or any application) actually care unless it's very rigid and can only read the data and schema from top to bottom only.

Adding order adds a lot of complexity without solving much of anything in this case in my opinion. Am I misunderstanding something?

Thanks,
Jack

On Jun 27, 2011, at 4:14 AM, James Godfrey <jgodf...@gmail.com> wrote:

> This design is seriously flawed in the same way that XML Schemas are
> flawed - they don't explicitly address the order of elements. In JSON,
> as with XML, the order of elements are completely irrelevant e.g.
>
> { "name" : "John Doe",
> "age" : 30 }
>
> { "age" : 30,
> "name" : "John Doe"}
>
> Should both be able to be validated using the same schema since they
> produce the same output. But given the complete lack of reference to
> element order in the draft each validator implementation might produce
> a different output.
>
> The draft needs to address the order of elements within JSON, and to
> make it actually useful it needs to "ignore" or normalise the data so
> elements on the same level of the hierarchy. I'd like to see explicit
> ordering of elements be an optional feature, but one which should be
> off by default since within the JSON language explicit ordering is
> unused by default.
>
> XML Schemas are very often not used simply because you have to keep
> XML elements in a specific order even though that was never a
> requirement in the XML markup its self.
>
> --
> 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.
>

[Dean Landolt]

On Mon, Jun 27, 2011 at 5:14 AM, James Godfrey <jgodf...@gmail.com> wrote:

This design is seriously flawed in the same way that XML Schemas are
flawed - they don't explicitly address the order of elements. In JSON,
as with XML, the order of elements are completely irrelevant e.g.

{ "name" : "John Doe",
 "age" : 30 }

{   "age" : 30,
 "name" : "John Doe"}

Should both be able to be validated using the same schema since they
produce the same output. But given the complete lack of reference to
element order in the draft each validator implementation might produce
a different output.

Why would each implementation produce a different output? Each implementation should produce the exact same output -- order is unspecified in JSON objects and thus nothing in JSON Schema depends on the order of object keys.

 

The draft needs to address the order of elements within JSON

JSON Schema cannot change JSON (in fact nothing can, not even Crock himself). If you need something ordered use a list -- that's what they're for.

 

, and to
make it actually useful it needs to "ignore" or normalise the data so
elements on the same level of the hierarchy.

Why would that actually make it useful? You find no other use in it as is? I agree a well defined normalization would be wonderful (for other reasons, though not for JSON Schema), but I don't think you realize just how involved a proposition that is ;)

 

I'd like to see explicit
ordering of elements be an optional feature, but one which should be
off by default since within the JSON language explicit ordering is
unused by default.

Oh? Well you already have what you want :)

And explicit ordering isn't unused by default...there is no default -- it's completely irrelevant.

 

XML Schemas are very often not used simply because you have to keep
XML elements in a specific order even though that was never a
requirement in the XML markup its self. 

I believe Jack already addressed this -- XSD is flexible in this regard, but even better is XPath-like path addressing, negating order by default -- which is why I prefer something like schematron (I'm toying with approaches to do schematron-like assertions in JSON).

The only place I can think of where order will matter is for presentation purposes, but you'd be better off preserving that ordering outside of the properties hash anyway.

[Paul C. Bryan]

JSON objects are explicitly unordered. Per JSON spec:

“An object is an unordered collection of zero or more name/value pairs…”

Based on this, if a validator implementation produces different output, it would be a defect.

Paul

On Mon, 2011-06-27 at 02:14 -0700, James Godfrey wrote:

This design is seriously flawed in the same way that XML Schemas are
flawed - they don't explicitly address the order of elements. In JSON,
as with XML, the order of elements are completely irrelevant e.g.

{ "name" : "John Doe",
  "age" : 30 }

{   "age" : 30,
  "name" : "John Doe"}

Should both be able to be validated using the same schema since they
produce the same output. But given the complete lack of reference to
element order in the draft each validator implementation might produce
a different output.

The draft needs to address the order of elements within JSON, and to
make it actually useful it needs to "ignore" or normalise the data so
elements on the same level of the hierarchy. I'd like to see explicit
ordering of elements be an optional feature, but one which should be
off by default since within the JSON language explicit ordering is
unused by default.

XML Schemas are very often not used simply because you have to keep
XML elements in a specific order even though that was never a
requirement in the XML markup its self.