Publish v5 draft

[awwright]

The v4 draft is expired, and people are still using it, and this is bad for some arbitrary reason that is bad enough the IETF still has an expiration system for Internet-drafts. I'd like to publish draft-05 within two month's time.

I propose doing the following things:

(1) The json-schema.org website should really get its own repository all to itself. Call it "json-schema.org" maybe

(2) I would expect current work to be on the master branch, so put current work there

(3) Tag commits that drafts are/were published against

(4) Create a "draft-05" milestone and label the relevant issues that we want to solve. Insert editor's notes for the other issues that will likely see changes in v6, but that we can't address within two months time.

If in doubt, copy https://github.com/httpwg since they seem to know what they're doing

(5) I'd like to see the master branch change structure to the following layout:

• archive/draft-$number/{core,schema,hyper-schema}.xml - the XML sources for previous, published drafts that we need reverse-comparability with
• archive/draft-$number/{schema,hyper-schema}.json - the meta-schemas themselves
• {core,schema,hyper-schema}.xml - current work on next draft to-be-published
• Makefile - calls xml2rfc to build %.html and %.txt from %.xml
• README - read this first

I've made a new repo from scratch along these lines, but maybe we can just rearrange the existing one, except I have no clue which file is 'current' and which files are 'archive'.

[Julian]

+1
On May 22, 2015 2:04 PM, "Acubed" [email protected] wrote:

The v4 draft is expired, and people are still using it, and this is bad
for some arbitrary reason that is bad enough the IETF still has an
expiration system for Internet-drafts. I'd like to publish draft-05 within
two month's time.

I propose doing the following things:

(1) The json-schema.org website should really get its own repository all
to itself. Call it "json-schema.org" maybe

(2) I would expect current work to be on the master branch, so put
current work there

(3) Tag commits that drafts are/were published against

(4) Create a "draft-05" milestone and label the relevant issues that we
want to solve. Insert editor's notes for the other issues that will likely
see changes in v6, but that we can't address within two months time.

If in doubt, copy https://github.com/httpwg since they seem to know what
they're doing

(5) I'd like to see the master branch change structure to the following
layout:

• archive/draft-$number/{core,schema,hyper-schema}.xml - the XML
  sources for previous, published drafts that we need reverse-comparability
  with
• archive/draft-$number/{schema,hyper-schema}.json - the meta-schemas
  themselves
• {core,schema,hyper-schema}.xml - current work on next draft
  to-be-published
• Makefile - calls xml2rfc to build %.html and %.txt from %.xml
• README - read this first

I've made a new repo from scratch along these lines, but maybe we can just
rearrange the existing one, except I have no clue which file is 'current'
and which files are 'archive'.

—
Reply to this email directly or view it on GitHub
#167.

[Fannon]

+1

[tmarrs]

+1

[epoberezkin]

Is there a list of changes for v5?

[awwright]

Part of this task is sorting through the current list of issues and tagging milestones.

I don't think there's a formal list of issues, but fixing incorrect vocabulary usage would top my list.

[epoberezkin]

So there are no actual changes for validation keywords?

[awwright]

@epoberezkin No one's started any work yet, this is just my feature request to get an active (unexpired) JSON Schema draft published

[epoberezkin]

Got it! Thanks

[donaldpipowitch]

I would love to see switch and constant in v5.

[awwright]

@donaldpipowitch The goal for this issue is to clean up outright errors and internal contradictions in the text, and to release a once-again-unexpired draft.

If those aren't already issues in the tracker, elsewhere, you should create a new one.

[donaldpipowitch]

With "issues in the tracker" do you mean issues in this Git repo?

[Relequestual]

Is there any clear leadership on this project? There's no infomation I can see that explains how to get involved.

[kriszyp]

I started the JSON Schema specification, and Gary Court helped shape and
author the first few versions. I stepped back, and Francis Galiegue led the
work on v4 (with help from others), and has since stepped back. Nick Lombard
owns the json-schema github organization. If someone wants to step up to
lead future efforts, they certainly are welcome.

[Relequestual]

@nickl- Hey! So Kris, Gary, and Francis stepped back from working on json-schema. Are there any leads apart from yourself owning the org here on github?

[Clemens-U]

Any progress on keep JSON schema specification going? As I already mentioned on other places I can manage the json-schema.org web pages if there is demand (@kriszyp).

[Relequestual]

There's a number of hyper-schema libaries / packages / modules for various languages now. Only a few are listed. It's clear updates would be benifical! =] Also happy to help out!

[geraintluff]

Hi all,

Kris and Gary passed responsibility on to Francis, who left it to me. I'm trying to shuffle things around and carve out time for it, but it's been difficult to find the headspace, and it's clear that more hands would be useful. By this point, it feels like there's so much stuff that needs to be done that it's been quite intimidating to even start, and I'm sorry for that.

(Although Nick Lombard created the GitHub organisation, he's not been involved with any of the specs or technical matters. I was also an owner on the organisation previously, but ended up off the list after some refactoring, and couldn't reach Nick to get reinstated, I don't know where he went.)

[epoberezkin]

I could help too. At the very least I would like to get involved in the discussion about standard changes.

[jasoniangreen]

I can help too. I work with @epoberezkin and given that we are making extensive use of json-schema in our current role, we can definitely find time for it.

[epoberezkin]

@geraintluff why don't you add couple people as collaborators, we could review pull requests at least?

[geraintluff]

Unfortunately, one of the problems is that since we (Francis and I and Kris and Gary) got locked out of the GitHub organisation (shortly before Nick Lombard disappeared quite a while ago), we don't actually have the permissions on this organisation to add collaborators.

In view of the proposed changes (which sound generally positive to me), and the above issue, I think we should consider moving to a new organisation.

[Clemens-U]

"... I think we should consider moving to a new organisation" Sounds like the only way to go if nobody can reach Nick anymore.

[geraintluff]

OK, so if we wanted to do that, I think some steps might be like:

• create new organisation, following something like @ACubed's proposed repo structure. I'm happy to do this, but am open to help (particularly if @ACubed already has something)
• collect people interested in various aspects (site, tests, spec discussion), permission them up appropriately
• each group agrees on change/review policy, how much consensus required to accept pull requests etc.
• once things are stable, @kriszyp points the json-schema.org domain at the new repo, and we replace the existing repos with notifications of the move.
• discuss v5 and publish updated spec(s)

For me: I'm very invested in the spec, and would love to continue collecting proposals and feedback on them etc. I'm also happy to continue editing the spec (I did the hyper-schema part for v4, and can extend both), but would prefer the spec discussions to be clearly separate from nailing down what's already been agreed.

I think with more people on board this could start moving quickly again - and actually being able to grant permissions for repos so helpful people can be effective would obviously be a big step in that. 😌

[Julian]

Eh, if we haven't already, we should reach out to GitHub support -- I
don't know if they'll help or say they can't, but it's worth a shot.

On Mon, Jun 22, 2015 at 7:43 AM, Geraint [email protected] wrote:

OK, so if we wanted to do that, I think some steps might be like:

• create new organisation, following something like @ACubed
  https://github.com/Acubed's proposed repo structure. I'm happy to do
  this, but am open to help (particularly if @ACubed
  https://github.com/Acubed already has something)
• collect people interested in various aspects (site, tests, spec
  discussion), permission them up appropriately
• each group agrees on change/review policy, how much consensus
  required to accept pull requests etc.
• once things are stable, @kriszyp https://github.com/kriszyp points
  the json-schema.org domain at the new repo, and we replace the
  existing repos with notifications of the move.
• discuss v5 and publish updated spec(s)

For me: I'm very invested in the spec, and would love to continue
collecting proposals and feedback on them etc. I'm also happy to continue
editing the spec (I did the hyper-schema part for v4, and can extend both),
but would prefer the spec discussions to be clearly separate from nailing
down what's already been agreed.

I think with more people on board this could start moving quickly again -
and actually being able to grant permissions for repos so helpful people
can be effective would obviously be a big step in that. [image:
😌]

—
Reply to this email directly or view it on GitHub
#167 (comment)
.

[Julian]

(Which I've just done. Will update back if they help.)

[geraintluff]

Cool - thanks. :)

I think that even if we get control of the organisation back, I feel a "clean slate" approach has some benefits. The structure could be made more clear, and there isn't clear separation of concerns between repos (web/spec/discussion).

[Julian]

It has some I agree, although we could certainly split up repos anyhow, and
try to not break bookmarks or search results as we do it, which would kind
of confuse.

On Mon, Jun 22, 2015 at 7:59 AM, Geraint [email protected] wrote:

Cool - thanks. :)

I think that even if we get control of the organisation back, a "clean
slate" approach has some benefits (splitting up repos etc.).

—
Reply to this email directly or view it on GitHub
#167 (comment)
.

[Relequestual]

Agreed with all of the above. Hopefully github support are gracious and have space in their policy and procedures for events like this. Getting back control of the github org would be benificial in making clear the cononical repositories.

/sidebar
I'm invested in json-schema, and I'd like to become more so. I'm involved in a group called The Global Alliance for Genomic Health, and we recetly identified AVRO not really fit for our purpose. I'd like to be able to push json-schema and json hyper-schema forward as a solution.

Hopefully this can lead to a number of key and highly skilled individuals from the GA4GH coming to help out with this project! =]
/

I haven't been involved in this sort of work before, but I'm keen to learn. Probably best suited to helping out with the site and documentation, but woud like to learn how I can contirbute to the specification also.

[geraintluff]

@Julian - from what I've seen, when you rename a repo then GitHub sets up forwarding, so visitors get a 303 to the new location.

[Relequestual]

@geraintluff I'm seeing lots of questions regarding the status of json-schema etc. Do you have access to update the google group description to add a link to here maybe?

[awwright]

@Lcfvs This would be an new feature, and thus (under this proposal) an issue for v6, if v5 is to iron out known problems with the current draft and get a new expiry-date.

Note, however, you can accomplish roughly the same thing you're asking with the "allOf" property:

{
    allOf: [
        {type:"string", description:"Must be a string"},
        {pattern:"\d", description:"Must contain a number"},
    ]
}

[the-t-in-rtf]

@ACubed, there is already a proposal to include custom error messages in v5:

https://github.com/json-schema/json-schema/wiki/Custom-error-messages-(v5-proposal)

What are the odds that will make it in?

[Lcfvs]

@ACubed, Ok, ok, waiting the next gen, then, because the allOf seems a few tricky.

@the-t-in-rtf, I like the idea about error messages, it improves the debug (and translations) but imho, the best way to do it, is to directly associate constraint & related message, for readability and for multiples constraints of the same type. (like multiple patterns, for example)

[brettz9]

Could I get a reply on my i18n comment?

[the-t-in-rtf]

@Lcfvs, the proposed standard is pretty clear about associating messages with the specific rule being broken. You can do it from inside the rule definition using the errors block in context, for example:

{
  "type": "string",
  "pattern": "^[A-Z]+$",
  "errors":  {
    "type": "You  must enter a string",
    "pattern": "The string must be UPPERCASE."
  }
}

You can also add rules from the document level using JSON pointers that refer to the deep location of the rule being broken (see the link for examples). This seems ideal for creating derived schemas or creating schemas with error messages in multiple languages.

[Lcfvs]

@the-t-in-rtf, hum, yeah, but how about multiple patterns, for example?

How to identify what pattern mismatch?

For me, on rule, one related error.

[awwright]

In the interest of keeping this issue on-topic, proposals and comments should be made at https://github.com/json-schema-org/json-schema-spec please (We really need peer review, by all means, comment there!)

[Lcfvs]

Ok, sorry. :|

[brettz9]

If you want to welcome comments, do you want to open the issue tracker there in addition to PRs?

[epoberezkin]

@ACubed I think the important thing to do is to move the website to the new organisation (I see the fork but I am not sure if www.json-schema.org is hosted there already) and to change the link on the home page so it points to the new org. While it points here, there will be comments here...

I also think it would be good to add more owners and contributors than just you to the new org, to avoid the risk of repeating the same situation that caused this migration. At least the same people who are now in json-schema organisation.

Also, I've made a couple of PRs for the website previously, I guess I have to re-submit them there?

[awwright]

@epoberezkin We might be able to handle those in the existing repo, someone with existing write permissions there would have to merge it in, but it's entirely possible

@geraintluff et el. Can we remove the CNAME file from the gh-pages branch? The website should now be hosted through https://github.com/json-schema-org/json-schema-org.github.io

[epoberezkin]

@ACubed thanks

[Relequestual]

Myself and @ACubed are only Members. Granted, ownership for myself is possibly unwranted with my current level of involvement, but I would be unable to abandon the project or leave it hanging.

I DID make some promises to do a big chunk of work for a new json-schema website. While the response was positive, further communication on how to proceed wasn't recpirpcated. I feel I was effectivly told to hold off till more work had been done to further to draft being made a spec.

I may come back to the effort over the next few months! We shall see.

[the-t-in-rtf]

Although I'm obviously looking forward to seeing the standard evolve, thanks very much to everyone who has stepped up to keep the standard alive.

[nemesifier]

I'm interested in contributing if you need some sort of help.

I'm currently involved in NetJSON a data interchange format that describes computer networks (network graph, configuration, monitoring) which is gaining some traction.
The (draft 0) NetJSON RFC currently mentions the JSON-Schema v4 draft and one implementation in particular makes heavy use of JSON-Schema.
NetJSON needs JSON-Schema for its implementation, so I want to give my contribution if possible.

I would really like to see one of these two proposals included in the v5:

• choices (v5 proposal to enhance enum)
• enumNames (v5 proposal)

Although I would prefer choices because it can be considered a way to decorate the schema just like title and description.

[BigBlueHat]

👍 to plans to add contains.

We're using JSON Schema (via ajv) in our testing platform for Web Annotation Data Model and having contains would greatly clarify situations like validating that a specific @context value is used.

[epoberezkin]

@BigBlueHat ajv supports contains btw

[BigBlueHat]

@epoberezkin yep! I found that here (and "reacted" to your note about it). Mostly just want to encourage it into the spec--and this seemed to be the right/only place to do that. 😄 Thanks for ajv!

[awwright]

@BigBlueHat @epoberezkin JSON-LD is defined in such a way that makes it difficult if not impossible to describe with JSON Schema, in a stateless fashion.

I'd be very interested in helping the TR, though.

Direct feature requests to the issue tracker at https://github.com/json-schema-org/json-schema-spec

[Relequestual]

@awwright ahem https://github.com/json-ld/json-ld.org/blob/master/schemas/jsonld-schema.json

@BigBlueHat dropped by irc. Found that for them.

[awwright]

It was a long and hard journey frought with polar bears, airplanes, sand castles, broken N64 controllers, and a busted speaker, but...

We did it!

https://tools.ietf.org/html/draft-wright-json-schema-00
https://tools.ietf.org/html/draft-wright-json-schema-validation-00
https://tools.ietf.org/html/draft-wright-json-schema-hyperschema-00

CC @Relequestual @epoberezkin @handrews et al.

I'll just wait on one more thing, getting @geraintluff et al. to sign off on the new series formally replacing the old series.

[darshakthakore]

Is the new draft going to be discussed in the working group meetings?
I didn't see it being listed in the jsonbis wg.

[awwright]

It has yet to be adopted by a WG. Idk if it's in-scope for jsonbis, but maybe someone else like art

[awwright]

The documents now formally supercede the old series, looks like Kris Zyp or the IETF Secretariat got around to approving it!