jsi-dev 0.0.0.pre.kramdown

data/README.md

@@ -0,0 +1,303 @@
+# JSI: JSON Schema Instantiation
+
+![Test CI Status](https://github.com/notEthan/jsi/actions/workflows/test.yml/badge.svg?branch=stable)
+[![Coverage Status](https://coveralls.io/repos/github/notEthan/jsi/badge.svg)](https://coveralls.io/github/notEthan/jsi)
+
+JSI offers an Object-Oriented representation for JSON data using JSON Schemas. Given your JSON Schemas, JSI constructs Ruby modules and classes which are used to instantiate your JSON data. These modules let you use JSON with all the niceties of OOP such as property accessors and application-defined instance methods.
+
+To learn more about JSON Schema see <https://json-schema.org/>.
+
+JSI marries object-oriented programming with JSON Schemas by associating a module with each schema, and extending every instance described by a schema with that module. When an application adds methods to a schema module, those methods can be used on its instances.
+
+A JSI instance aims to offer a fairly unobtrusive wrapper around its JSON data, which is usually a Hash (JSON Object) or Array described by one or more JSON Schemas. JSI instances have accessors for property names described by schemas, schema validation, and other nice things. Mostly though, you use a JSI as you would use its underlying data, calling the same methods (e.g. `#[]`, `#map`, `#repeated_permutation`) and passing it to anything that duck-types expecting `#to_ary` or `#to_hash`.
+
+Note: The canonical location of this README is on [RubyDoc](http://rubydoc.info/gems/jsi/). When viewed on [Github](https://github.com/notEthan/jsi/), it may be inconsistent with the latest released gem, and Yardoc links will not work.
+
+## Example
+
+Words are boring, let's code. Here's a schema in yaml:
+
+```yaml
+$schema: "http://json-schema.org/draft-07/schema"
+description: "A Contact"
+type: "object"
+properties:
+  name: {type: "string"}
+  phone:
+    type: "array"
+    items:
+      description: "A phone number"
+      type: "object"
+      properties:
+        location: {type: "string"}
+        number: {type: "string"}
+```
+
+We pass that to {JSI.new_schema} which will instantiate a JSI Schema which represents it:
+
+```ruby
+# this would usually load YAML or JSON; the schema object is inlined for copypastability.
+contact_schema = JSI.new_schema({"$schema" => "http://json-schema.org/draft-07/schema", "description" => "A Contact", "type" => "object", "properties" => {"name" => {"type" => "string"}, "phone" => {"type" => "array", "items" => {"type" => "object", "properties" => {"location" => {"type" => "string"}, "number" => {"type" => "string"}}}}}})
+```
+
+We name the module that JSI will use when instantiating a contact. Named modules are better to work with, and JSI will indicate the names of schema modules in its `#inspect` output.
+
+```ruby
+Contact = contact_schema.jsi_schema_module
+```
+
+Note: it is more concise to instantiate the schema module with the shortcut {JSI.new_schema_module}, i.e. `Contact = JSI.new_schema_module(...)`. This example includes the intermediate step to help show all that is happening.
+
+To instantiate the schema, we need some JSON data (expressed here as YAML)
+
+```yaml
+name: bill
+phone:
+- location: home
+  number: "555"
+nickname: big b
+```
+
+So, if we construct an instance like:
+
+```ruby
+# this would usually load YAML or JSON; the schema instance is inlined for copypastability.
+bill = Contact.new_jsi({"name" => "bill", "phone" => [{"location" => "home", "number" => "555"}], "nickname" => "big b"})
+# => #{<JSI (Contact)>
+#   "name" => "bill",
+#   "phone" => #[<JSI (Contact.properties["phone"])>
+#     #{<JSI (Contact.properties["phone"].items)>
+#       "location" => "home",
+#       "number" => "555"
+#     }
+#   ],
+#   "nickname" => "big b"
+# }
+```
+
+Note that the hash keys are strings. JSI, being designed with JSON in mind, is geared toward string keys.
+
+We get accessors for the Contact:
+
+```ruby
+bill.name
+# => "bill"
+```
+
+but also nested accessors - `#phone` is an instance of its array-type schema, and each phone item is an instance of another object-type schema with `#location` and `#number` accessors:
+
+```ruby
+bill.phone.map(&:location)
+# => ["home"]
+```
+
+We also get validations, as you'd expect given that's largely what json-schema exists to do:
+
+```ruby
+bill.jsi_valid?
+# => true
+```
+
+... and validations on the nested schema instances (`#phone` here), showing in this example validation failure on /phone/0/number:
+
+```ruby
+bad = Contact.new_jsi({'phone' => [{'number' => [5, 5, 5]}]})
+# => #{<JSI (Contact)>
+#   "phone" => #[<JSI (Contact.properties["phone"])>
+#     #{<JSI (Contact.properties["phone"].items)>
+#       "number" => #[<JSI (Contact.properties["phone"].items.properties["number"])> 5, 5, 5]
+#     }
+#   ]
+# }
+bad.phone.jsi_validate
+# => #<JSI::Validation::FullResult
+#  @validation_errors=
+#   #<Set: {#<JSI::Validation::Error
+#      message: "instance type does not match `type` value",
+#      keyword: "type",
+#      schema: #{<JSI (JSI::JSONSchemaDraft07) Schema> "type" => "string"},
+#      instance_ptr: JSI::Ptr["phone", 0, "number"],
+#      instance_document: {"phone"=>[{"number"=>[5, 5, 5]}]}
+#   >,
+#  ...
+# >
+```
+
+Since the underlying instance is a ruby hash (json object), we can use it like a hash with `#[]` or, say, `#transform_values`:
+
+```ruby
+# note that #size here is actually referring to multiple different methods;
+# for name and nickname it is String#size but for phone it is Array#size.
+bill.transform_values(&:size)
+# => {"name" => 4, "phone" => 1, "nickname" => 5}
+
+bill['nickname']
+# => "big b"
+```
+
+There's plenty more JSI has to offer, but this should give you a pretty good idea of basic usage.
+
+## Terminology and Concepts
+
+- `JSI::Base` is the base class for each JSI schema class representing instances of JSON Schemas.
+- a "JSI Schema" is a JSON Schema, instantiated as (usually) a JSI::Base described by a metaschema (see the sections on Metaschemas below). a JSI Schema is an instance of the module `JSI::Schema`.
+- a "JSI Schema Module" is a module which represents one schema, dynamically created by that Schema. Instances of that schema are extended with its JSI schema module. applications may reopen these modules to add functionality to JSI instances described by a given schema.
+- a "JSI schema class" is a subclass of `JSI::Base` representing one or more JSON schemas. Instances of such a class are described by all of the represented schemas. A JSI schema class includes the JSI schema module of each represented schema.
+- "instance" is a term that is significantly overloaded in this space, so documentation will attempt to be clear what kind of instance is meant:
+  - a schema instance refers broadly to a data structure that is described by a JSON schema.
+  - a JSI instance (or just "a JSI") is a ruby object instantiating a JSI schema class (subclass of `JSI::Base`). This wraps the content of the schema instance (see `JSI::Base#jsi_instance`), and ties it to the schemas which describe the instance (`JSI::Base#jsi_schemas`).
+- "schema" refers to either a parsed JSON schema (generally a ruby Hash) or a JSI schema.
+
+## Supported specification versions
+
+JSI supports these JSON Schema specification versions:
+
+| Version | `$schema` URI                             | JSI Schema Module |
+| ---     | ---                                       | ---               |
+| Draft 4 | `http://json-schema.org/draft-04/schema#` | {JSI::JSONSchemaDraft04} |
+| Draft 6 | `http://json-schema.org/draft-06/schema#` | {JSI::JSONSchemaDraft06} |
+| Draft 7 | `http://json-schema.org/draft-07/schema#` | {JSI::JSONSchemaDraft07} |
+
+## JSI and Object Oriented Programming
+
+Instantiating your schema is a starting point. But, since the major point of object-oriented programming is applying methods to your objects, of course you want to be able to define your own methods. To do this we reopen the JSI module we defined. Referring back to the Example section above, we reopen the `Contact` module:
+
+```ruby
+module Contact
+  def phone_numbers
+    phone.map(&:number)
+  end
+  def name
+    super + ' esq.'
+  end
+  def name=(name)
+    super(name.chomp(' esq.'))
+  end
+end
+
+bill.phone_numbers
+# => ["555"]
+
+bill.name
+# => "bill esq."
+bill.name = 'rob esq.'
+# => "rob esq."
+bill['name']
+# => "rob"
+```
+
+`#phone_numbers` is a new method returning each number in the `phone` array - pretty straightforward.
+
+For `#name` and `#name=`, we're overriding existing accessor methods. note the use of `super` - this invokes the accessor methods defined by JSI which these override. You could alternatively use `self['name']` and `self['name']=` in these methods, with the same effect as `super`.
+
+Working with subschemas is just about as easy as with root schemas.
+
+You can subscript or use property accessors on a JSI schema module to refer to the schema modules of its subschemas, e.g.:
+
+```ruby
+Contact.properties['phone'].items
+# => Contact.properties["phone"].items (JSI Schema Module)
+```
+
+Opening a subschema module with [`module_exec`](https://ruby-doc.org/core/Module.html#method-i-module_exec), you can add methods to instances of the subschema.
+
+```ruby
+Contact.properties['phone'].items.module_exec do
+  def number_with_dashes
+    number.split(//).join('-')
+  end
+end
+bill.phone.first.number_with_dashes
+# => "5-5-5"
+```
+
+A recommended convention for naming subschemas is to define them in the namespace of the module of their
+parent schema. The module can then be opened to add methods to the subschema's module.
+
+```ruby
+module Contact
+  Phone = properties['phone'].items
+  module Phone
+    def number_with_dashes
+      number.split(//).join('-')
+    end
+  end
+end
+```
+
+However, that is only a convention, and a flat namespace works fine too.
+
+```ruby
+ContactPhone = Contact.properties['phone'].items
+module ContactPhone
+  def number_with_dashes
+    number.split(//).join('-')
+  end
+end
+```
+
+### A note on Classes
+
+The classes used to instantiate JSIs are dynamically generated subclasses of JSI::Base which include the JSI Schema Module of each schema describing the given instance. These are mostly intended to be ignored: applications aren't expected to instantiate these directly (rather, `#new_jsi` on a Schema or Schema Module is intended), and they are not intended for subclassing or method definition (applications should instead define methods on a schema's {JSI::Schema#jsi_schema_module}).
+
+## Registration
+
+In order for references across documents (generally from a `$ref` schema keyword) to resolve, JSI provides a registry (a {JSI::SchemaRegistry}) which associates URIs with schemas (or resources containing schemas). The default registry is accessible on {JSI.schema_registry}.
+
+Schemas instantiated with `.new_schema`, and their subschemas, are by default registered with `JSI.schema_registry` if they are identified by an absolute URI. This can be controlled by params `register` and `schema_registry`.
+
+Schemas can automatically be lazily loaded by registering a block which instantiates them with {JSI::SchemaRegistry#autoload_uri} (see its documentation).
+
+## Validation
+
+JSI implements all required features, and many optional features, for validation according to supported JSON Schema specifications. To validate instances, see methods {JSI::Base#jsi_validate}, {JSI::Base#jsi_valid?}, {JSI::Schema#instance_validate}, {JSI::Schema#instance_valid?}.
+
+The following optional features are not completely supported:
+
+- The `format` keyword does not perform any validation.
+- Regular expressions are interpreted by Ruby's Regexp class, whereas JSON Schema recommends interpreting these as ECMA 262 regular expressions. Certain expressions behave differently, particularly `^` and `$`.
+- Keywords `contentMediaType` and `contentEncoding` do not perform validation.
+
+## Metaschemas
+
+A metaschema is a schema which describes schemas. Likewise, a schema is an instance of a metaschema.
+
+In JSI, a schema is generally a JSI::Base instance whose schemas include a metaschema.
+
+A self-descriptive metaschema - most commonly one of the JSON schema draft metaschemas - is an object whose schemas include itself. This is instantiated in JSI as a JSI::MetaschemaNode, a special subclass of JSI::Base.
+
+## ActiveRecord serialization
+
+A really excellent place to use JSI is when dealing with serialized columns in ActiveRecord.
+
+Let's say you're sticking to JSON types in the database - you have to do so if you're using JSON columns, or JSON serialization, and if you have dealt with arbitrary yaml- or marshal-serialized objects in ruby, you have probably found that approach has its shortcomings when the implementation of your classes changes.
+
+But if your database contains JSON, then your deserialized objects in ruby are likewise Hash / Array / basic types. You have to use subscripts instead of accessors, and you don't have any way to add methods to your data types.
+
+JSI gives you the best of both with {JSI::JSICoder}. This coder dumps objects which are simple JSON types, and loads instances of a specified JSON Schema. Here's an example, supposing a `users` table with a JSON column `contact_info` to be instantiated using the `Contact` schema module defined in the Example section above:
+
+```ruby
+class User < ActiveRecord::Base
+  serialize :contact_info, JSI::JSICoder.new(Contact)
+end
+```
+
+Now `user.contact_info` will be instantiated as a `Contact` JSI instance, from the JSON type in the database, with Contact's accessors, validations, and user-defined instance methods.
+
+See the gem [`arms`](https://github.com/notEthan/arms) if you wish to serialize the dumped JSON-compatible objects further as text.
+
+## Keying Hashes (JSON Objects)
+
+Unlike Ruby, JSON only supports string keys. It is recommended to use strings as hash keys for all JSI instances, but JSI does not enforce this, nor does it do any key conversion. You may also use [ActiveSupport::HashWithIndifferentAccess](https://api.rubyonrails.org/classes/ActiveSupport/HashWithIndifferentAccess.html) as the instance of a JSI in order to gain the benefits that offers over a plain hash. Note that activesupport is not a dependency of jsi and would be required separately for this.
+
+## Contributing
+
+Issues and pull requests are welcome on GitHub at https://github.com/notEthan/jsi.
+
+## License
+
+[<img align="right" src="https://github.com/notEthan/jsi/raw/v0.3.0/resources/icons/AGPL-3.0.png">](https://www.gnu.org/licenses/agpl-3.0.html)
+
+JSI is licensed under the terms of the [GNU Affero General Public License version 3](https://www.gnu.org/licenses/agpl-3.0.html).
+
+Unlike the MIT or BSD licenses more commonly used with Ruby gems, this license requires that if you modify JSI and propagate your changes, e.g. by including it in a web application, your modified version must be publicly available. The common path of forking on Github should satisfy this requirement.

data/docs/glossary.md

@@ -0,0 +1,281 @@
+# Glossary
+
+
+## Background
+
+The terminology JSI uses comes from a number of sources:
+
+- [JSON Schema](https://json-schema.org/) and its [specifications](https://json-schema.org/specification-links.html)
+  - The [JSON Schema Glossary](https://json-schema.org/learn/glossary.html)
+- [JSON](https://www.json.org/) and its specification
+- Tree data structure ([Wikipedia](https://en.wikipedia.org/wiki/Tree_(data_structure)))
+- Object-oriented programming ([Wikipedia](https://en.wikipedia.org/wiki/Object-oriented_programming))
+- The Ruby programming language
+- [JSON Pointer](https://www.rfc-editor.org/rfc/rfc6901)
+
+The terminology from these can be contradictory, e.g. 'object' in JSON meaning what is a Hash in Ruby, but 'object' in Ruby meaning any object as in object-oriented programming. This glossary aims to clarify any ambiguity and introduce any terms which may not be familiar to the reader.
+
+
+## Terms
+
+
+- ### JSI
+
+  [JSI]: #JSI
+  [a JSI]: #JSI
+
+  JSI is the name of this library. As a [countable](https://en.wikipedia.org/wiki/Count_noun), "a JSI" refers to the library's instantiation of an instance of a set of [schema]s. This is a Ruby instance of a subclass of {JSI::Base}.
+
+  The subclass of JSI::Base which a JSI is instantiated as includes the [schema module] of each schema that describes the instance (its {JSI::Base#jsi_schemas}), as well as type-specific modules for [array] and [hash/object] instances.
+
+
+- ### node
+
+  [node]: #node
+
+  A node is an element in a [document] at a location identified by a [pointer].
+
+  In JSI a node generally means [a JSI] - a JSI::Base instance is often referred to just as "a JSI", but is referred to as a node in the context of its relationship to other nodes in its document.
+
+
+- ### node content
+
+  [content]: #node_content
+
+  The content of a [node] is the parsed JSON instance.
+  It is generally a Ruby Hash, Array, String, Integer, Float or BigDecimal, true, false, or nil.
+
+  This content is referred to as the 'instance' in relation to [schema]s that describe it.
+
+  See {JSI::Base#jsi_node_content} (also aliased as {JSI::Base#jsi_instance}.
+
+
+- ### document
+
+  [document]: #document
+
+  The document is the [content] of the [root] [node].
+
+  See {JSI::Base#jsi_document}.
+
+
+- ### root
+
+  [root]: #root
+
+  A [node] representing the whole of a [document].
+
+  Its [pointer] is empty (has zero [token]s).
+
+  See {JSI::Base#jsi_root_node}.
+
+
+- ### complex
+
+  [complex]: #complex
+
+  A [node] that can have [child]ren is complex. Its [content] is an [array] or a [hash/object].
+
+  Hash and Array nodes can mostly be used like Ruby Hashes and Arrays. JSI defines or delegates the methods of Hash and Array with nearly perfect compatibility, and supports [implicit conversion](https://docs.ruby-lang.org/en/master/implicit_conversion_rdoc.html) with `#to_hash` and `#to_ary`.
+
+  These nodes also support implicit conversion for the instance's content, treating any object responding to `#to_hash` or `#to_ary` like Hash or Array - though it is most common that actual Hash and Array instances will be the content. (This support may be incomplete for node content that is implicitly convertible but does not respond to certain methods, especially `#[]`.)
+
+
+- ### child
+
+  [child]: #child
+
+  A [node] immediately below another node, its [parent]. Identified by one [token] relative to the parent.
+
+  See {JSI::Base#[]}.
+
+
+- ### parent
+
+  [parent]: #parent
+
+  A [node] immediately above some number of other nodes, its [child]ren. A node that can be a parent node must be [complex].
+
+  See {JSI::Base#jsi_parent_node}.
+
+
+- ### descendent
+
+  [descendent]: #descendent
+
+  A [node] anywhere below another node, its [ancestor]. Identified by a relative [pointer]. A node is considered to be a descendent of itself (at an empty relative pointer).
+
+  See {JSI::Base#jsi_descendent_node}, {JSI::Base#jsi_each_descendent_node}.
+
+
+- ### ancestor
+
+  [ancestor]: #ancestor
+
+  A [node] anywhere above another node, its [descendent]. A node is considered to be an ancestor of itself, and the [root] node is an ancestor of every node in the [document].
+
+  See {JSI::Base#jsi_ancestor_nodes}.
+
+
+- ### token
+
+  [token]: #token
+
+  An [array] [index] or [hash/object] [property name/key] that identifies a child node of its parent. Generally a String or non-negative Integer. [JSON Pointer](https://www.rfc-editor.org/rfc/rfc6901) calls this a "reference token".
+
+  A sequence of tokens comprises a [pointer].
+
+
+- ### pointer
+
+  [pointer]: #pointer
+
+  A sequence of [token]s which identifies a [descendent] of a [node], instantiated as a {JSI::Ptr}.
+
+  [JSON Pointers](https://www.rfc-editor.org/rfc/rfc6901) are parsed to JSI pointers.
+
+  A pointer may be referred to as 'absolute' when identifying a descendent of the root node (see {JSI::Base#jsi_ptr}), or 'relative' identifying a descendent of any node (such as the pointer passed to {JSI::Base#jsi_descendent_node}).
+
+
+- ### hash/object
+
+  [hash/object]: #hash_object
+
+  The [content] of a [complex] JSI Hash [node] (see {JSI::Base::HashNode}), representing a JSON object, is typically a Ruby Hash, or [implicitly convertible](https://docs.ruby-lang.org/en/master/implicit_conversion_rdoc.html) with `#to_hash`.
+
+
+- ### array
+
+  [array]: #array
+
+  The [content] of a [complex] JSI Array [node] (see {JSI::Base::ArrayNode}) is typically a Ruby Array, or [implicitly convertible](https://docs.ruby-lang.org/en/master/implicit_conversion_rdoc.html) with `#to_ary`.
+
+
+- ### property name/key
+
+  [property name/key]: #property_name_key
+
+  A [token] identifying a [child] of a [hash/object] [node]. In Ruby, a Hash key; in JSON Schema, an object property name. Property names are expected to be strings, though Ruby Hash keys do not have this limitation. Note that Symbols are not Strings, and Symbols should not be used in JSI [node content].
+
+  Property names can be described by schemas (using the `propertyNames` keyword), and can be JSI instances of those schemas. See {JSI::Base::HashNode#jsi_each_propertyName}.
+
+
+- ### index
+
+  [index]: #index
+
+  A [token] identifying a [child] of an [array] [node]. A non-negative integer.
+
+
+- ### instance
+
+  [instance]: #instance
+
+  A heavily-overloaded term. Context should make it clear in what sense it is being used. 'Instance' can refer to an *object* or a *relationship*, in Ruby or JSON Schema or JSI instantiation:
+
+    - JSON Schema: the _instance_ (JSON data) is an _instance_ (relationship) of [JSON Schemas][schema] that describe it
+    - Ruby: the _instance_ (an Object) is an _instance_ (relationship) of a Class and included Modules
+    - JSI: the _instance_ ([a JSI]) is an _instance_ (relationship) of JSI Schemas
+
+  These all operate in parallel in JSI: a JSI instance represents a JSON instance, it is described by JSI Schemas which represent JSON Schemas, and it is a Ruby instance of [JSI Schema Modules][schema module] of each schema that describes it.
+
+
+- ### schema
+
+  [schema]: #schema
+
+  A JSI Schema is [a JSI] that represents a JSON Schema. It is a Ruby instance of the module {JSI::Schema}.
+
+  A schema describes a set of [instance]s. Any JSI instance that is described by a given schema is a Ruby instance of that schema's [schema module].
+
+  A schema is described by a [meta-schema] and is a Ruby instance of that meta-schema's [schema module].
+
+
+- ### schema module
+
+  [schema module]: #schema_module
+
+  A JSI Schema Module is a Ruby module associated with a particular [schema]. Any JSI [instance] that is described by the schema is a Ruby instance of the schema's schema module. This is a {JSI::SchemaModule}.
+
+  See {JSI::Schema#jsi_schema_module}.
+
+  A JSI Schema Module is not to be confused with the module {JSI::Schema} - a schema *is* a Ruby instance of the module JSI::Schema, and it *has* a JSI Schema Module. The module JSI::Schema is included on the JSI Schema module of a [meta-schema].
+
+
+- ### meta-schema
+
+  [meta-schema]: #meta-schema
+
+  A meta-schema is a [schema] that describes schemas, i.e. [instance]s of the meta-schema are schemas.
+
+  As with any other instance, a JSI schema includes the [schema module] of the meta-schema that describes it. The meta-schema's schema module defines the functionality for its instances to behave as schemas, including the module {JSI::Schema} as well as other modules implementing functionality particular to that meta-schema.
+
+  A meta-schema is described by a meta-schema, which may be itself or another meta-schema. Examples of self-describing meta-schemas are the JSON Schema meta-schemas. An example of the latter is the [schema describing the OpenAPI v3.0 Schema object](https://github.com/OAI/OpenAPI-Specification/blob/3.0.3/schemas/v3.0/schema.yaml#L203), which describes schemas in OpenAPI documents, but is itself described by JSON Schema draft 04.
+
+  A self-describing meta-schema is a Ruby instance of its own schema module.
+
+  See {JSI::Schema::DescribesSchema} and {JSI::SchemaModule::DescribesSchemaModule}, {JSI::Schema#describes_schema?} and {JSI::Schema#describes_schema!}
+
+
+- ### resource
+
+  [resource]: #resource
+
+  A resource, or schema resource, is either:
+
+  - A [schema] that is identified by an absolute URI (declared with an id keyword)
+  - The root of a document containing schemas, whether or not the root is itself a schema. (Technically the root of any document can be considered a resource, but it is only useful when the document contains schemas.)
+
+  The nearest ancestor that is a resource is a node's "resource root" - this is distinct from the [root] node of the whole document.
+
+  Relative URIs and [pointer]s used by a schema (e.g. in `$ref` or `$id`) are resolved relative to its resource root and that resource's id.
+
+  See {JSI::Schema#schema_resource_root}
+
+
+- ### schema application
+
+  [schema application]: #schema_application
+
+  The computation of schemas that apply describing a [node] at a given location. This involves several steps:
+
+  - **root indicated schemas**: Application begins with the schemas (usually just one schema) indicated as describing the [root]. `#new_jsi` is invoked on a {JSI::SchemaSet} of the indicated schemas, or more commonly on one schema or [schema module]. These are the root's {JSI::Base#jsi_indicated_schemas}.
+  - **root applied schemas**: [in-place application] is performed on each of the root indicated schemas to compute its applied schemas, i.e. its {JSI::Base#jsi_schemas}.
+  - Descending from the root to the given node, for each [token] of the node's [pointer]:
+    - **child indicated schemas**: [child application] is performed on each applied schema of the parent on the current token. This results in the child's indicated schemas.
+    - **child applied schemas**: [in-place application] is performed on each child indicated schema to compute its applied schemas.
+
+  The schemas that apply describing the node are the result of the final in-place application.
+
+
+- ### child application
+
+  [child application]: #child_application
+
+  The computation of subschemas of a given schema that apply to a [child] of a [complex] instance on a given [token]. These come from subschemas defined on child applicator keywords such as `properties` and `items`. The result may be an empty schema set if no such keywords are present or none apply.
+
+
+- ### in-place application
+
+  [in-place application]: #in_place_application
+
+  The resolution or expansion of a schema to a set of **applied schemas** for a given instance. "In-place" means all the schemas apply to the same location in the instance, in contrast to [child application]. This is a recursive process.
+
+  - If the schema contains a `$ref` keyword:
+    - The reference is resolved and in-place application is performed on the resolved schema.
+    - The schema containing the reference is _not_ applied.
+    - No other applicator keywords should be present; if present they are ignored.
+
+    The resulting applied schemas are those of the reference's resolved schema.
+
+  - Otherwise:
+    - The schema applies itself (it is added to the set of applied schemas).
+    - Any in-place applicator keywords (`anyOf`, `dependencies`, etc.) are evaluated for subschemas that apply to the instance. For each such subschema, in-place application is performed and the resulting schemas are added to the applied schemas.
+
+    The resulting applied schemas are the given schema plus the results of in-place application of each applicable subschema.
+
+- ### validation
+
+  [validation]: #validation
+
+  The process of determining whether a given [instance] is valid against the [schema]s that describe it, or collecting validation errors indicating why the instance is not valid. See {JSI::Base#jsi_valid?}, {JSI::Base#jsi_validate}, {JSI::Schema#instance_valid?}, {JSI::Schema#instance_validate}

data/jsi.gemspec

@@ -0,0 +1,30 @@
+require_relative "lib/jsi/version"
+
+Gem::Specification.new do |spec|
+  spec.name    = "jsi-dev"
+  spec.version = JSI::VERSION
+  spec.authors = ["Ethan"]
+  spec.email   = ["ethan.jsi@unth.net"]
+
+  spec.summary     = "JSI: JSON Schema Instantiation"
+  spec.description = "JSI offers an Object-Oriented representation for JSON data using JSON Schemas"
+  spec.homepage    = "https://github.com/notEthan/jsi"
+  spec.license     = "AGPL-3.0"
+
+  spec.files = [
+    'LICENSE.md',
+    'CHANGELOG.md',
+    'README.md',
+    'readme.rb',
+    '.yardopts',
+    'jsi.gemspec',
+    *Dir['lib/**/*'],
+    *Dir['\\{resources\\}/schemas/**/*'],
+    *Dir['docs/**/*'],
+  ].reject { |f| File.lstat(f).ftype == 'directory' }
+
+  spec.require_paths = ["lib"]
+
+  spec.add_dependency "addressable", '~> 2.3'
+  spec.add_development_dependency "maruku"
+end