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?

I think people should be allowed to go off and develop a spec but they
should not be allowed to grab a false sense of authority through an
inappropriate name grab. That had bad results in the XML world and I can't
see this effort working out any better.


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.

It should be possible to have a schema language that is essentially
language neutral and encoding neutral. 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.

It should be possible to use a schema to map a data structure that can be
represented conveniently in any sensible modern programming language (i.e.
anything from Perl to Java, C# but not necessarily FORTRAN, COBOL or the
like) to at least a subset of any sensible encoding (JSON, XML, ASN.1)


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.


At any rate I suggest that either

1) the authors of JSON Schema start using a different name or
2) Everyone else with ideas for a schema for JSON busilly pollute the name
space by introducing their own plans named JSON Schema until the authors
back down.


Since there is no consensus that JSON needs a schema, I can't see how there
can be a consensus for one particular proposal.

In fact I don't think JSON does need a schema either. We need a schema for
describing protocol data structures that can be reified as JSON or other
data formats.

On Wed, Sep 19, 2012 at 1:05 PM, Francis Galiegue <fgaliegue@gmail.com>wrote:

> On Wed, Sep 19, 2012 at 6:59 PM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
> [...]
> >
> >
> > Just where is JSON Pointer intended to be used? Who is using it?
> >
>
> JSON Schema, for instance, even though only implicitly for now. The
> next version will mandate JSON Reference support and, as such, JSON
> Pointer (which is the fragment part of a JSON Reference).
>
> >
> > Pretty much every modern programming language has adopted a notation that
> > uses dots for member extraction and square braces for array indices. I
> don't
> > see a particularly good reason to invent another way to extract
> information
> > from a data structure.
> >
> > In C# and Java the notation would be x.y[1].
> >
>
> Again, programming languages do not enter the picture. What is wanted
> is an unambiguous way to address any part of a JSON value.
>
> Oh, and "." is a valid object member name. And so is "/" for that
> matter. And so is "", and so is "\x00".
>
> [...]
> >
> > I can't see why I would want to have a different syntax to extract
> elements
> > after a data object has been JSON encoded. What is the value of such a
> > standard meant to be?
> >
>
> Language-proof, future-proof, covers all corner cases. If these are
> not arguments, I don't know what is.
>
> Oh, and the fact that it can be used in URI fragments.
>
> > This looks like an attempt to reinvent a wheel that has already been
> tried
> > and tested.
> >
>
> Tried and tested _by a few subset of programming languages_.
>
> --
> Francis Galiegue, fgaliegue@gmail.com
> 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)
>



-- 
Website: http://hallambaker.com/