json-schema human readable or machine readable #38

Closed
nickl- opened this Issue Nov 24, 2012 · 31 comments

Comments

Projects
None yet
5 participants
Owner

nickl- commented Nov 24, 2012

@geraintluff brought up an interesting topic at #37 (comment) that he would like to see more people writing schemas than people writing tools.

This was as a response to @fge suggesting that dependencies be an array with 1 to many constraint which I agree, is much simpler to implement (machine readable) albeit slightly more "human readable" to also allow single strings.

Allowing both string and array of dependent properties makes implementation more complex, specifying the type more complex and ultimately more complex for the end user having to keep track of what it is supposed to be now. Keeping in mind that for us "dep" == ["dep"] in the end, which is certainly not the case for our machine friends.

Is there really such an improvement in the first instance compared to the second to justify the extra complexity?

{
    "dependencies": {
        "lastName": "firstName",
        "middleName": ["firstName", "lastName"]
    }
}
{
    "dependencies": {
        "lastName": ["firstName"],
        "middleName": ["firstName", "lastName"]
    }
}

The question can better be resolved if you agree on who the audience is. Should JSON be considered for humans to read and edit or should it be simple for machines to parse and understand.
Would you rather type complex JSON schemas in a text editor or would you prefer a specialized tool specifically geared at manipulating the underlying JSON for you, able to import information from forms or services to improve productivity while ensuring that the JSON is valid and the document is valid json-schema at all times. If the latter is your preference then it matters not what JSON looks like, now does it?

Lets hear what you think, is JSON for humans or for machines. Knowing this will help us focus our efforts to best satisfy the target consumers of json-schema.

I vote for tools to manipulate schemas, what would you prefer?

Member

geraintluff commented Nov 24, 2012

Hey - thought I'd chime in.

Firstly - the difference between "dependencies": "firstName" and "dependencies": ["firstName"] is not that big for humans. I'm even willing to remove array/string dependencies, as the longer syntax (schema dependency with required) has now become shorter.

Member

geraintluff commented Nov 24, 2012

Now for the actual question - whether human readability/writeability should be a priority at all:

I think it is incredibly important that JSON Schema is easily readable and human-writeable. For me, this is useful when doing debugging and so on while doing JSON Schema development. In fact, it's been very useful when discussing JSON Schema here and on the Google Group.

I also completely disagree that we have to choose between tools or human-readability. I don't think that if we keep JSON Schema as human-readable, that suddenly nobody will make tools for it. That's not the question. People are already making tools! In fact, (related to the last paragraph) I think that if the standard is not human-readable, then making tools will become harder - harder to test, harder to debug.

Also, imagine trying to present computer-efficient but human-unfriendly schema format to your boss, and convincing them that it's better than the (technically inferior, but boss-friendly) alternative. When people are considering adopting a standard, one of the big factors is definitely "Does this format make instant sense to me?". There are actually competing schema formats for JSON out there - for example, JSchema. And if the JSON Schema standard becomes long, impenetrable, and readable only by machines, then I think we will lose ground to them.

There is a reason that we use nice keywords like "additionalProperties" instead of just "ap". The second one is smaller to store and faster to transfer, but we don't use it. Why? Because it's impenetrable to humans. The easier it is to understand for humans who haven't even read the standard, the more wide-spread it can become. Look at Python - the main reason it took off as fast as it did is because it looks like pseudo-code. A BASIC programmer can come along and understand it just as easily as a Java programmer.

I think that it's also worth mentioning that many of the tools for doing things like writing/editing JSON Schema don't exist yet. But if the standard is not human-friendly, then we place an additional burden on anyone writing tools. The little human-friendly details don't actually cost that much more effort when programming tools, but they are important in allowing people to get excited about the standard.

@garycourt @kriszyp - if you have views, I'd love to hear them. I think this is a pretty important question.

Owner

nickl- commented Nov 25, 2012

@geraintluff thank you for the detailed reply you raised some interesting topics but maybe I failed to get the question across and the motivator is also not addressed by your argument.

Before we get to that, the following completely went over my head.

I'm even willing to remove array/string dependencies, as the longer syntax (schema dependency with required) has now become shorter.

Do I need to understand what you're trying to say there, then you wil need to explain please, or are you just saying as a matter of fact?

The question is: ** Is JSON innately human read-/modifiable? **

I'm a programmer can read fluent assembler and even a code snippet in brainfuck might make me smile. Is it human friendly? Certainly not just like JSON where a simple misplaced comma will render the whole document invalid. Is it heman friendly? I can't tell how many times I've been stuck staring at a json document I've manually edited trying to fin out WTF and I know to look for the commas. Is it human friendly? Come hell or high water I have to find the fault or loose the packet there's no undo now, I should never have touched it. Is it human friendly?

None of the mentioned obstacles are addressable under the work order json-schema, they are syntax faults and it makes no difference what it's called. To save your frustrations my advice would be to turn to our trusty friends who actually understand why it's a square bracket and not a brace or why that comma should be over there for me and you single quotes are like double quotes and back tics are used when the other two aren'h accepted. The machine can do precise formatting and apply syntax highlighting which will quickly expose the predicament and you can live to change JSON again another day.

Even the sheer fact that you brought the Python argument to the table is proof enough to support my argument that JSON is not human friendly and is better served to machines. No matter how descriptive the words or choice of type representation is going to get us to use json-schema to validate fields by hand, you'd make a list and use a red pen. Even your argument that displaying it to the boss is of no consequence. Have you ever bothered to explain, even present a soap envelope to your boss? Do they know what HTTP headers look like or ever scene a TCP/IP packet before? How did we explain PKI and SSL not by presenting the payload and algorithms, that's what they pay you for and the more obscure you make it the better for your bottom line =)

No how we present it to them at first was this tiny little lock it the corner and several similarly obscure sets of windows to navigate the signing authorities with. These days we have green and red and blue and orange and grey blocks on the adressbar and it's even more cumbersome to see your certificate but we don't care. I have a secure connection with my bank no one can see my bank statements - fail!!! The machine gets tasked to present it, just like your'e not going to take the JS/CSS/Html documents to the boss, you'd open them in the browser would you not? Now why do you want to go show him how pretty your json-schema for the anual party venue suggestion service. You will only impress him if you bring up a form where you can select the type, constraints and required properties.

None of these are the point really. Why I feel we should decide is because it will effect our decision making. If we target for humans then we want to be as flexible as possible and as close to a list as we can. (see checklist and red pen) It does not matter how many full document scans it may require to find relationships nor would we care, at the risk of dragging dead cows from ditch, if you type 1 "1" Yes True "Yes" "true" one uno ok eheh or any of the above on the contrary we would make every effort to accommodate the user. On the other hand the machine would probably prefer 1 and it could me ok, yes, alright, agreed or simply one more than zero we don't worry about it as the machine knows.

The argument comparing additionalProperties with ap is an issue of ambiguity and will not factor in these equations. Whether to use a list, as apposed to an object or a comma separated string for what it's worth these are based on the preference of the target audience and we either focus on the one or the other. It will be folly to attempt to satisfy both.

In case it is still not clear:
Is it friendly to star of with? Since we can't do anything about that why bother. The machines like it like chocolates and thats why we use it anyway.

the result of a targeted focus, for purposes to settle discourse easier and have a mutual goal in hand, will not automatically produce obscure layouts or cryptic descriptions, anything your boss would be scared of or which might embarres you at the next SchemaCon it's the difference between using a string or an array or an object instead but not both or all three unless there is simply no other way we can simplify it to satisfy the requirement.

I don't think I can make it any more clear than that, maybe you can explain what you consider human readable/modifiable JSON the type your boss can't wait to fire up notepad and start scoping out the booking form for next years anual event. If that is the deciding factors then perhaps YAML is something to consider, my 2cents.

Member

geraintluff commented Nov 26, 2012

the more obscure you make it the better for your bottom line

That does not sound like the kind of standard I want to make.

Is it friendly to start off with?

the type your boss can't wait to fire up notepad and start scoping out the booking form for next years anual event

The thing is, this was pretty much my immediate reaction when I first read JSON Schema. It looked simple, and it looked intuitive, and the ability to write schemas in a simple text editor is really good. Things like:

{
    "type": ["object", "null"],
    ...
}

are extremely easy to understand. I think that the current format is already friendly, but every time we change things to be harder for humans (but easier for computers) then it becomes more and more difficult for programmers to get excited about it.

It's the difference between using a string or an array or an object instead but not both or all three unless there is simply no other way we can simplify it to satisfy the requirement

What I'm saying is - the tools can cope with more than one data type. It is really not difficult to write tools that can deal with arrays OR objects.

Computers are there to make our lives easier. If we make schema-writing more difficult for humans, just so that a computer can save 0.5% execution time, then that is a mistake.

Certainly not just like JSON where a simple misplaced comma will render the whole document invalid. Is it heman friendly? I can't tell how many times I've been stuck staring at a json document I've manually edited trying to fin out WTF and I know to look for the commas. Is it human friendly?

So... you are saying that JSON is not a human-friendly format, because syntax errors are still possible? And if JSON is not human-friendly, then we should give up on any JSON-based format being at all human-intelligable as well?

I'm a programmer can read fluent assembler and even a code snippet in brainfuck might make me smile

Wait - you smile at BrainFuck and Assembler, but you are saying that JSON is not human-friendly?

Owner

nickl- commented Dec 1, 2012

That does not sound like the kind of standard I want to make.

If you read my remark in context, you will see I am referring to what you present to your boss. I don't see what leads you to think I am suggesting we create an obscure standard.

It is really not difficult to write tools that can deal with arrays OR objects

It is more difficult then only using one! More difficult to define, write and ultimately requires more cycles to process, is this increase in effort justified? No matter how marginal. Whichever side of the equation you choose to stand are you willing to follow that completely? To simplify what I am asking you to decide:

a) target audience humans parsing and editing raw json: strategy ALWAYS supply as many compatible formats as possible, be lenient to structure if you can fix syntak faults highlight and format output.

b) taget audience machines will parse and manipulate the payload. ALWAYS choose the one most efficient data type for the task, aim at single sweep parsing, present in unicode, as buffered streams and consider caching strategies for longevity.

I am saying ALWAYS as I consider trying to accomplish both is like trying to catch your own tail. Avoiding to answer the question and pick one of the two options is not being constructive. Please motivate your choice.

Wait - you smile at BrainFuck and Assembler, but you are saying that JSON is not human-friendly?

What is your point exactly? How does me being able to read assembler effect JSON's user friendliness in any way?

Member

geraintluff commented Dec 2, 2012

I didn't chose an option because I don't feel represented by either of your answers.

Whichever side of the equation you choose to stand are you willing to follow that completely?

I think this is the point: No. You are asking me to choose between two complete polar opposites:

  1. as human-friendly as possible (accepting 1, "1", "yes", and "true" instead of true) which I do not want
  2. as computer-friendly as possible, regardless of how difficult it is for humans to read/write, which I do not want

You are right - we cannot be 100% human-friendly and 100% computer-friendly at the same time. But I am not asking for that!

I believe that the humans will be writing schemas, and reading schemas. They will not be doing the actual validation of the data, but they will still be creating schemas, and reading other people's schemas in order to edit them. We cannot and must not make people rely on using tools to create/edit these schemas, especially when the tools don't exist yet - my text editor has highlighting for JSON, but not JSON Schema!

In short: I think we already have a good compromise. For me, version 3 of JSON Schema has a reasonable balance between human-friendliness and computer-friendliness - it must be possible to improve the standard without breaking that.

Member

geraintluff commented Dec 2, 2012

An example of maintaining balance: version 3 allowed schemas in type arrays. That was a bit confusing for humans, and very confusing for computers.

So, in version 4, the anyOf and oneOf keywords were introduced (yay!). This makes things easier for schema authors and people programming new tools and simpler for machines! It's a really big difference, and it's a step forwards for both humans and machines.

So, I think that change is win-win.

However, there was another proposed change: not allowing arrays in type. I think this makes things more complicated for humans, but simpler for machines. So the question is: Is it worth it? Does it move the balance in an acceptable way?

Personally, no - but I'm happy to discuss it, and when everyone's had their say, we can move the compromise. But move it, not get rid of it completely.

Geraint has said what I might have, with sufficient time. It is not either-or.

Owner

nickl- commented Dec 5, 2012

For clarity

You are right - we cannot be 100% human-friendly and 100% computer-friendly at the same time. But I am not asking for that!

We can however ensure 100% for any side you want, but that unfortunately requires that you choose.

What I was saying (which got lost with your summary): I consider attempting to find middle ground to be a fool's errand. Anything less than 100% is a fail iow

  • If neither one made it to 100% we've lost the plot completely == fail,
  • 99% is just as bad as 50%
    • damage has been done and
    • we missed the optimum
    • == fail.

Hence the fool's errand, we have no hope of success.

Points we do agree on (I hope):

  • There may be an initial period where access to tools are limited (there are schema editors already available)
  • Users would prefer to use tools if they are available
  • We see it as progress when tools make editing schemas by hand redundant.
  • Users will not process or parse schema ever (editing only) - this includes validation,link or form creation or whatever other reason we actually want to use schemas for.

Points that may not be under consideration (I guess)

  • Once appropriate interfaces(tools) exist to view and manipulate what the json-schema represents we wont care to look at the raw json again and it will only be a memory, recorded on wikipedia, something we tell our kids about as ghost stories around the camp fire to scare them.
  • The easier it is to compute the quicker you can whip up a tool without a fuzz
  • The sooner we have tools the less people will need/want to read the json
  • Imagine json-schema becomes a standard and it gets used everywhere is the choice we make now considerable when billions of transactions need to be processed while users sit and wait wondering whats taking so long wishing they could go manually create a schema document like we did in the old days. Then we never had to wait for validation.

We cannot and must not make people rely on using tools to create/edit

And why is that? Do you think you actually have a say in the matter?

especially when the tools don't exist yet -

Oh but they do:
http://www.jsonschema.net/
http://jsonwidget.org/example.php?sample=electoschema&user=normal

my text editor has highlighting for JSON, but not JSON Schema!

Surely that can't be right?!?!

I think this makes things more complicated for humans, but simpler for machines. So the question is: Is it worth it? Does it move the balance in an acceptable way?

Are you able to answer the question now?

My 2 penny on the matter (to be honest - I couldn't get myself to read all the entire wall of text)

For me, any JSON-schema is code. And as with any other code, it will be read more times than it will be written, and more times than it will be executed.
So my vote goes for making it as readable as possible, and that can mean: less boilerplate (good for writing it as well), but also making it as less ambiguous as possible.

With that in mind, me personally -

  • I take this approach for dependencies #37 (comment) as @geraintluff mentioned in his first reply here
  • for type - leave it as it is today as I haven't heard anyone complaining that it is utterly confusing
Member

geraintluff commented Dec 7, 2012

For me, any JSON-schema is code. And as with any other code, it will be read more times than it will be written

👍 - nicely put. :)

fge commented Dec 15, 2012

@andreineculau:

for type - leave it as it is today as I haven't heard anyone complaining that it is utterly confusing

What do you mean by "as it is today"?

@fge as we "compromised" in #39 (comment) . The additional constraints make sense, but don't change the usage from v3

fge commented Dec 15, 2012

OK, so, an array of strings then?

As to the whole topic: I went to extremes, I must admit, and that is not really a question of "a few less lines of Java". It is just that given the uses I have seen of JSON Schema so far, I have never seen a multiple type definition.

Not that it does not have any uses, mind. I do agree though that I went too far on "dependencies". I should also mention that Jackson has schema generation, but not quite there yet -- I have proposed to work on it when I get the time, but Jackson also has other areas of improvement ;)

Member

geraintluff commented Dec 17, 2012

I have never seen a multiple type definition

I agree they're not common. The one I've used most often so far is

{
    "type": ["object", "null"]
}

OK, so, an array of strings then?

For dependencies, yes.

You are absolutely right that the most common case for type is a single value, so we should continue to allow plain string values for type. I think that agrees with what @andreineculau was saying?

@geraintluff yes, don't know if I left room for interpretation previously

dependencies: always an array of unique strings

type: string* or array of (unique strings or subschemas)

*I personally wouldn't mind removing the option of string value for type and only going with an array, just like dependencies. I think it's very brittle to think in terms of... now the majority uses type as string, tomorrow the majority uses type as array, let's change the specs back and forth. Given the point I made earlier about treating the schema as code, and considering readability - I honestly don't see ["string"] less readable than "string", especially in the context of all type values are always arrays

fge commented Dec 17, 2012

@andreineculau

type is a very fundamental keyword, and the "single string" option is by far the most used, so it should stay as is. What has been removed, though, is "any". For the simple reason that writing:

{ "type": "any" }

is equivalent to the empty schema, ie {}. You may also want to look at issue #42. It accounts for the new dependencies and type keyword definitions.

@geraintluff: still waiting for a new draft ;)

@fge "by far the most used" implies 1) we have statistics on JSON Schema usage 2) it will stay the same forever 3) that if the "statistics" change, then the spec changes as well

Owner

nickl- commented Dec 17, 2012

optional fields

I agree they're not common. The one I've used most often so far is

{
    "type": ["object", "null"]
}

This is an odd way to specify an optional field, don't you agree?

polymorphism

One practical example I can think of would be different types presented as search results:

{
    "type": ["blog", "event", "comment", "article", "review"]
}

Which, if considering OOP patterns can simply be solved with polymorphism.

{
   "type": "content"
}

Is it currently possible to define inheritance? This will completely negate any need for multiple types by grouping dispersed types through common parent abstractions.

transformation

Another scenario is where multiple "value-types" represent the same value, may be data that originates from different systems where alternative conventions are applied, a fairly common manifestation can be seen in practice with configuration switches:

{
    "animation": "on",
    "rotate": "off",
    "show-splash": true,
    "hide-desktop": false,
    "repeat": 1,
    "delay": 0,
    "screensaver": "enabled",
    "password-protect": "disabled"
}

Purely using multiple types cannot properly define this type of schema

{
    "type": ["number", "boolean", "string"]
}

Although it is now possible to assign different types there is no way to differentiate, for example, between "on" and "enabled" or "1" and "true" for that matter nor does it prevent you from using "maybe" or 69 as values, Whatever the motivations are for these use cases, storing multiple representations of the same value is not a practice that should be encouraged in favour of data normalization through transformation.

{
    "type": "boolean",
    "transform": ["/on|enabled|1|true/true/", "/off|disabled|0|false/false/"]
}

Can you imagine the nightmare if you wanted to see everything that is enabled. Through transformation the data is normalized when the value is assigned and will only fail validation if no valid result could be translated. While allowing different "value-types" the data is normalized and retrieving all disabled fields now is as simple as WHERE NOT X

conclusion

Even in loosely typed programming languages a variable is only of a specific type at any given instance, which will be no different to json data. With java as you might know everything extends java.lang.Object which simplified collections and allowed you to add any type [1] to a Vector and is compareable to what you are suggesting here. Now ask yourself, if this was so desirable why would we have overcomplicated the language and syntax through the mandatory definition requirement of generics? Let that be a lesson to us all.

The majority of stakeholders could not even imagine why we might ever need multiple types so we are obviously addressing edge cases. We have however shown viable use cases where this may be a requirement but hopefully we've shown that not only are there better ways to address the requirement properly but allowing the mere possibility as innocent as it may seem encourages its use and as we've seen, nothing good can come of it.

I doubt anyone can motivate against what we've known for quite some time, but you are always welcome to try and we encourage that. Unless a viable counter argument presents itself that is able to motivate the usefulness whatsoever of having this and that it outweighs the risks. I consider it unanimous, we vote for type as single string, compatible with previous versions of the spec, encourages normalized data and polymorphism, simplifies usage for both machine and human, prevents common pitfalls not easily rectified by disallowing the alternative. Sounds like win win win win win win win win to me.

[1] In practice java would actually use polymorphism and still only allows a single type for collections storing everything as java.lang.Object.

fge commented Dec 17, 2012

@nickL

Your first "type" examples are all illegal, draft v3 defines the legal values for type as being one of the defined primitive types or any. And draft v4 removes any since it is basically useless ({"type": "any"} or an empty schema are the same).

What was your point with these examples?

Owner

nickl- commented Dec 17, 2012

"by far the most used" implies 1) we have statistics on JSON Schema usage 2) it will stay the same forever 3) that if the "statistics" change, then the spec changes as well

@andreineculau "most used" currently would only imply "imaginable/motivate-able use cases" at best due to 1) lack of usage statistics. 2) it will stay the same unless someone could imagine and motivate a plausible alternative. 3) and if a.) a need has been identified b.) someone makes the effort to compile an RFC and presents it to IETF c.) and only if a consensus is reached any current specification for any whatever reason, can be changed.

Nor does the mere presence of an approved spec necessarily compel anyone to follow it merely marks a majority agreement on the specific topic at a given point in time while only considering a finite amount af variance presented at such junction and ultimately only offers a means by which to collaborate consistently between different implementations with greater ease. We can only hope that it seves the common purpose.

Member

geraintluff commented Dec 18, 2012

One practical example I can think of would be different types presented as search results:

{
    "type": ["blog", "event", "comment", "article", "review"]
}

Which, if considering OOP patterns can simply be solved with polymorphism.

{
   "type": "content"
}

That is completely not how "type" works. You are probably thinking about "oneOf" instead.

Owner

nickl- commented Dec 26, 2012

@fge and @geraintluff you are so stuck on the rules that you completely disregard the whole topic, did you actually read the post? What is mentioned is speculative and the definitions were explanatory but if you couldn't even follow the chain of conversation then I guess these concepts would have missed you as well.

What was your point with these examples?

It clearly starts off from @geraintluff 's comment which if you trace it back was in reference to @fge 's comment

I have never seen a multiple type definition

There's a saying in Afrikaans (which is also used in Dutch and might be true for German as well)

'n Goeie begrip het 'n halwe woord nodig. (a good understanding/intellect needs but half a word)

Now that you've both proven your exceptional understanding of the keyword type and thank you for pointing it out for us, duly noted. Now may I ask that kindly you read the post which raises some interesting questions and please apply that exceptional intellect of yours, we all know is just burning for release, to the actually topics so that we may hear your valuable opinions as you apply yourselves outside of the box and share those thoughts in technicolour instead of this black and white ramblings of little use.

If you don't mind.

fge commented Jan 2, 2013

This is getting nowhere, so --> .close()

@fge fge closed this Jan 2, 2013

Owner

nickl- commented Jan 5, 2013

@fge Ouch, so there is also nothing to be said for Polymorphism and attribute inheritance, instead even after making a plea to please read past the "illegal" use of types I would really like to hear your opinion, this is the response?

This is getting nowhere, so --> .close()

I take it you mind then? My bad...

If you don't mind, I will quietly write about something related which I have found to keep record and because its something I care about which may help someone else, who knows. @fge and @geraintluff please ignore its just me being constructive.

XML has a specification called Canonicalization to address issues related to attribute inheritance
http://www.w3.org/TR/xml-exc-c14n/
http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/

Which may translate to something like this to represent the relational model. Since the use of the extends keyword was abandoned we can use it to favour the correct application based on name.

{
    "id": "urn:schema:greatgrandparent",
    "extends": {
        "id": "urn:schema:grandparent",
        "extends": {
            "id": "urn:schema:parent",
            "extends": {
                "id": "urn:schema:child",
                "type": "object",
                "title": "etc etc as per usual"
            }                    
        }
    }
}

The XML cascading does not translate well to JSON maybe this makes more sense inverted with a down up relation:

{
    "id": "urn:schema:child",
    "type": "object",
    "title": "etc etc as per usual",
    "extends": {
       "id": "urn:schema:parent",
        "extends": {
           "id": "urn:schema:grandparent",
            "extends": {
                "id": "urn:schema:greatgrandparent",
            }                    
        }
    }
}

We can also flatten the nesting without changing the meaning which will be easier on the parser too.

{
    "id": "urn:schema:child",
    "type": "object",
    "title": "etc etc as per usual",
    "extends": [
        {
            "id": "urn:schema:parent"
        },
        {
            "id": "urn:schema:grandparent"
        },
        {
            "id": "urn:schema:greatgrandparent"
        }
    ]
}

The novelty really, which I haven't thought of before, is the fact that the ancestry is referenced in its entirety and available without the need for additional lookups to find assess an is-a condition is possible with the schema alone, which is actually identical to the way an object is perceived when dealing with that instance, it is a child of all its parents and attributes inherited and self contained.

{
    "id": "urn:schema:child",
    "type": "object",
    "title": "etc etc as per usual",
    "properties": {
        "is_hot": {
            "type": "boolean"
        },
        "is_cold": {
            "type": "boolean"
        }
    },
    "extends": [
        {
            "id": "urn:schema:parent",
            "type": "object",
            "properties": {
                "is_hot": {
                    "type": "boolean"
                },
                "is_warm": {
                    "type": "boolean"
                }
            }
        },
        {
            "id": "urn:schema:grandparent",
            "type": "object",
            "properties": {
                "is_freezing": {
                    "type": "boolean"
                },
                "is_warm": {
                    "type": "boolean"
                }
            }
        },
        {
            "id": "urn:schema:greatgrandparent",
            "type": "object",
            "properties": {
                "is_wet": {
                    "type": "boolean"
                },
                "is_cold": {
                    "type": "boolean"
                }
            }
        }
    ]
}

The resulting data set as seen from the top down, each child overwriting the parent property.

{
    "is_hot": true,
    "is_cold": false,
    "is_warm": true,
    "is_freezing": false,
    "is_wet": true
}

Nothing stops us from referencing schemas yet we still know that we are dealing with a greatgrandparent type without much effort.

{
    "id": "urn:schema:child",
    "type": "object",
    "title": "etc etc as per usual",
    "properties": {
        "is_hot": {
            "type": "boolean"
        },
        "is_cold": {
            "type": "boolean"
        }
    },
    "extends": [
        {
            "$ref": "http://json-schema.org/parent"
        },
        {
            "$ref": "http://json-schema.org/grandparent"
        },
        {
            "$ref": "http://json-schema.org/greatgrandparent"
        }
    ]
}

There are so many possibilities of what we can do with this stuff it gets me really excited.

Member

geraintluff commented Jan 5, 2013

I don't understand what you're getting at.

The syntax you propose is the correct use of the "extends" keywords from v3 (renamed to "allOf" in v4). Are you trying to propose something new that I'm somehow missing, or are you just getting excited about the existing functionality?

Owner

nickl- commented Jan 6, 2013

@fge and @geraintluff please ignore its just me being constructive.

@geraintluff You shouldn't waste your time on this as you say just me being constructive.

What really has me excited are the ids did you see the use of URNs I'm thinking it can just replace json pointer all together, we can call them JSON Schema pointer.

But don't fret I know its ridiculous and in no way will it ever be part of a spec, so no need to pay it any attention.
Instead why don't you do something really awesome and restore my privileges, you know its the right thing to do.

Member

geraintluff commented Jan 6, 2013

What really has me excited are the ids did you see the use of URNs I'm thinking it can just replace json pointer all together, we can call them JSON Schema pointer.

URNs are of course valid URIs for use in "id". However, you appear to be thinking of some special-case behaviour for the urn:schema:... bases - could you elaborate on that? I don't understand how JSON Pointer would be used in your examples, so I don't understand how you're replacing them.

Could you give an example that uses JSON Pointer, and then an example of how your new syntax would replace JSON Pointer? Maybe that would make it clearer.

unsubscribe

fge commented Jan 6, 2013

Please, please, let's stop it here. @andreineculau , sorry that you have been brought up in that, this was really not the intent.

Owner

nickl- commented Jan 6, 2013

@fge +1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment