There are a lot of places in the code where we rescue any error, at all.
That's quite dangerous, as it could conceal bugs.

I've changed it so that we always specify which error class we want to
catch. Mostly it's been a minor change, but there are two API changes:

* When it comes to loading data I've had to introduce an explicit list
  of protocols which we can load json over (otherwise it's possible to
  have a uri with a scheme that makes no sense - it'd still be a valid
  uri but loading from it is impossible). I've used the list of
  protocols that addressable recognizes for now.
* No matter what JSON parser you use, we now always raise a
  JSON::Schema::JsonParseError. Without doing this it would be tricky to
  handle parser errors identically, for all parsers (the other option
  would be to catch a long list of potential parse errors, but this
  seems more sensible).

Older versions raised ruby warnings

Enabled warnings when running tests

…n the schema

Explicitly notes :strict overrides any required properties set in schema

…dator

register_format_validator on default_validator

Conflicts:
	test/test-suite

…dator

Test all versions in test_custom_format

Update README.textile to fix schema validation example

Only rescue errors explicitly

Addressible's URI parsing shows up at the top of the profiler for our use case.

This patch adds a cache to JSON::Util::URI.normalized_uri, to trade CPU time for memory.

There are other expensive Addressible methods that should be cached elsewhere.

benchmark: https://github.com/mjc/json-schema-perf

MRI 2.2.2 before: 825.363  (± 6.2%) i/s
MRI 2.2.2 after:  1.436k (± 4.5%) i/s

1.74x faster

JRuby 1.7.20 before: 1.445k (± 2.5%) i/s
JRuby 1.7.20 after: 2.272k (± 6.1%) i/s

1.57x faster

Addressable::URI#fragment= triggers a revalidation of the URL, which is
super slow.  Don't do this when it isn't necessary.

Hopefully this will make it easier to change in future

For the unused variable `validator`

Remove ruby warnings

Redux: speed up JSON::Validator.validate

If you pass an unrecognized object for the schema, we should be raising a SchemaParseError, however instead right now a NameError is raised, beacuse we're not correctly qualifying the error class with it's module.

I've corrected the class/module name and added tests.

This fixes voxpupuli#292

…le-for-schema-parse-errors

Made sure we include the module name for SchemaParseErrors

Forgot to do this in the PR

This started as a straight up automated conversion via pandoc:

  pandoc README.textile -o README.md

I then followed up by fixing the images it did not convert properly,
removing extraneous backslashes that it added, and adding finced code
blocks for syntax highlighting. I also replaced <code>...</code>
with backticks and adjusted some whitespace.

Convert readme to markdown

Making it a little easier to read the descriptions of the three validate methods.

Update README.md

Reformatted the examples to make them easier to read

Turns out that before:

* if you had a ref that included a colon, the text before the colon was
  treated as the scheme and the text after the colon as a path
* the unescape_uri method was actually only parsing the path of the
  uri (therefore anything before a colon was being stripped when passed
  to unescape_uri)

Fixes voxpupuli#319

…cters-in-refs

Made it possible to have refs that include URI-special characters

To avoid unintended side-effects

Tidy up tests

Travis doesn't support 2.3 yet

…after merge mistakes