Roadmap for the JSON Schema spec

[Joe Littlejohn]

Hi all,

I've been following this group closely since last year and I'm
interested to know if we're close to a final/GA/non-draft version of
the spec. I get the impression that there are lots of projects
springing up around JSON schema but they're often left in a bit of a
limbo state as the spec is evolving and there's still no end in sight.

Is there a roadmap for the spec? or an idea of the minimum set of
changes that need to be added/discussed before the spec can be taken
out of draft? It feels like the discussion is beginning to dry up, and
with over three years since the original Ajaxian post[1] I'm wondering
if it may be time to produce 'v1.0'. It's clear that a huge amount of
work has going in so far and I think finalising the spec would
encourage the rest of the world to start running with JSON Schema and
build some solid tool support around it.

Cheers,

Joe

[1] http://ajaxian.com/archives/json-news-json-schema-and-json-referencing

[Kris Zyp]

I think more important than any type of version number is furtherance in
IETF standardization. And I am not exactly sure what comes next in that
process. Version 3 was a very significant release with a large amount of
contribution from a broad number of users. We could do another release
sometime soon, but there certainly hasn't been very many issues raised,
version 3 seems to meeting a pretty broad set of users/needs. There have
a few issues that still need addressing for version 4, but it definitely
looks like it would be a minor/polish release. This convergence does
seem like it would point to getting closer to some sort of "readiness"
of the spec.
Thanks,
Kris

[Gary Court]

I would like to see the primary focus of revision 4 to be on improving
the wording of the specification. In many places in the current spec,
we say the same thing multiple ways. We should standardize on
terminology, clean up the examples, and perhaps separate schema
implementation details from validator implementation details.

As a secondary focus, we could put out a "last call for new features".
Once revision 4 is published, revision 5 would only be for improving
the wording of the specification. Once published, this would be our
standardized IETF publication. Any future features could then be
addendums to this specification.

I have two new features I'd like to propose for the next revision, but
need to do some experimentation with them before posting my ideas. I'm
away on vacation for the next 3 weeks, but would be willing to start
working on finishing up JSON Schema once I'm back.

Thoughts?

-Gary

> --
> 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.
>
>

[Robin Berjon]

On Feb 16, 2011, at 02:58 , Gary Court wrote:
> I would like to see the primary focus of revision 4 to be on improving
> the wording of the specification. In many places in the current spec,
> we say the same thing multiple ways. We should standardize on
> terminology, clean up the examples, and perhaps separate schema
> implementation details from validator implementation details.

Where specification wording is required, I can only warmly recommend reading this document:

http://www.w3.org/TR/test-methodology/

The title makes it sound rather obscure (which might be warranted since writing specs is a rather obscure art a lot of the time) and not everything in the document applies to IETF specifications, but there is excellent on how to write a tight specification.

The core idea is that the most important part of any specification is the parts of it that are testable conformance requirements. That is, requirements placed on implementations so that they may interoperate. They must be testable because otherwise you can't figure out whether an implementation conforms or not. The rest of a spec is just about providing context, clarifying intent, etc. The document essentially explains common pitfalls in writing such requirements, and how to build ones that are rock-solid.

If you're in a hurry, sections 2 and 4 are probably the most relevant.

--
Robin Berjon
Robineko (http://robineko.com/)

[Mike Sassak]

A big yes to both points. The wording in the spec could definitely be
improved here and there, but little does so much to clarify intent as
a well-chosen example or two.

I've been working on a Ruby library for v3 validation called
Jschematic, and I've been using Cucumber to specify the behavior as I
go. Being able to include examples and conformance tests from the spec
in the features themselves would be super useful. The library is still
a few refactorings away from a first release, but you can see the
features I've been using to specify behavior here:
https://github.com/msassak/jschematic/tree/master/features.

Mike

> --
> Robin Berjon
>  Robineko (http://robineko.com/)
>
>
>

[Gary Court]

Excellent document! Thanks for finding this!

-Gary