Re: [apps-discuss] JSON Schema considered harmful

[Francis Galiegue <[e-mail]>]

On Wed, Sep 19, 2012 at 7:30 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> One of the biggest mistakes that was made in the XML world was to allow one
> group of authors to develop a specification and call it 'XML Schema'. I
> think we are at risk of making the same mistake here.
>
> The more I hear about this effort, the less I like it. The approach seems to
> be needlessly complex for a start. There should be no need to have a pointer
> structure in a modern data modelling language, none. C# and Java don't use
> pointers, so why are they needed in JSON Schema?
>

OK, sorry, but that is a _very limited view of JSON Schema_.

JSON Schema was there _far_before the GitHub group came into the
picture, and FYI, JSON Reference and JSON Pointer came into light
_before the GitHub group took over_. Go read both the JSON Reference
and JSON Pointer I-Ds: do you see my name in them as an author? NO.
Only as a side note for JSON Reference because I highlighted the
dangers of a loop.

And please get a grip: before you say the approach is "needlessly
complex", have a look at what is being done. It is _precisely_ because
JSON Schema needs input that no drafts are submitted at the moment.
They are still in the process of being written.

And JSON Schema, even in its latest incarnation, is used: consider the
Google discovery API.

>
> Using a schema to develop a protocol is a very good idea but each and every
> schema language I have had to use has been botched. XML schema has two
> separate type systems. ASN.1 schema is arcane. We must not let that happen
> to JSON.
>

Go read the proposed specs. Do you see ASN.1 anywhere?

Link: https://github.com/json-schema/json-schema

> It should be possible to have a schema language that is essentially language
> neutral and encoding neutral.

Yes, and that is _precisely_ what the GitHub group is aiming for. And
you contradict yourself ohsomuch by saying that dot should be
preferred to solidus, for one.

> Pretty much every programming language in
> current use has the same set of intrinsic types (bytes, int16, int32, int64,
> strings (unicode), chars (unicode), real32, real64, boolean), and at least
> one form of enumerated collection (arrays, lists, sets). For protocol design
> it is very useful to add in standard representations for Binary and DateTime
> intrinsict types as base64 encoded strings are easier to deal with than
> arrays of decimal bytes and we already have an IETF string representation
> for time.
>

You obvioulsy haven't read neither the past nor the present.

[...]
>
> Where the XML Schema effort went wrong was they tried to support every
> feature of DTDs and they gave the schema designer the ability to map a data
> structure onto multiple different encodings. Which is pretty weird. Making
> standards is the process of making design choices that don't matter.
> Providing multiple ways to serialize the same data structure is a harmful
> option.
>

Oh dear. You really HAVE NOT read anything of the work being done by
the GitHub organization, have you?

Schema, Pointer. Those are just names. Please go carefully read the
current productions at said organization. I certainly DO NOT want to
replicate XSD. XSD and LSD have only one letter apart, and I, and the
GitHub organization, DO NOT want to go there.

Sorry for being so blunt, but I cannot stand this kind of "feedback"
from people who DO NOT EVEN TRY AND SEE WHAT IS BEING DONE.

-- 
Francis Galiegue, [e-mail]
JSON Schema: https://github.com/json-schema
"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)