DRY spec generation, Integrate changes to v1

[pwalsh]

Implements the following

• Remove everything that is not Frictionless Data related
• Integrate our JSON Schemas as a single point of truth for everything common across all specs.
  • Much, much less ambiguity!
  • Direct alignment between spec and implementation!
• Generate specs from JSON Schemas and a templating pattern extracted from analysis of all the freeform work to date
• Make it easier to generate RFCs
• Standardise all language across all specs (prime example: field, attribute, property are used interchangeably)
• Remove author in preference for contributors with roles. Currently two roles: author and maintainer
• Change license type to license name
• Remove optional fields wording in favour of simpler required and recommended
• Explicitly describe, for each constraint, the types it applies to, and, that all constraints apply to cast values. esp. clarify wording around date types
• Closes Rename JSON Table Schema to Table Schema #334
• Closes [WIP] Data Resource spec; new DRY way to write a spec #335
• Closes [WIP] Stablize specifications to version 1 #330
• Closes Make datapackage.resources[].name required? #309
• Closes Improve readability of code blocks #318
• Closes Consider removing dataDependencies for v1 #341
• Closes Create a template for writing a data package spec #196
• Closes Data Package "profiles" #87
• Closes Split out a resource spec #327
• Closes Create spec as data structure for writing to RFC, other formats, etc #328
• Closes Proposed Revisions #298
• Closes [dp] Simplify Schema Referencing and Loading #325
• Closes Consider support for JSON References #295
• Closes Change language for "delimiter" on CSV Dialect #340
• Closes Restore licenses for dual-licensing. #236
• Closes License should be a URL, not a OD license ID #146
• Closes Remove datapackage reference from jsontableschema foreign keys for v1? #314
• Closes Provide default missingValues? #359
• Closes Change missingValue to missingValues plural #353
• Closes Heavily copyedit for clarity and ease of reading. #356
• Closes Should maximum/minimum have the same fmt/pattern? #296
• Closes Merging path into data #336
• Removes the need for a seperate schemas repository - everything is generated here in a single place, including the registry
• Makes the registry itself a JSON file. Users still contribute to the CSV, but consuming code uses JSON

[pwalsh]

@rufuspollock everything I am working on is converging on this branch. I'm now doing a commit per issue. There is no better way around it now - this branch changes the way the specs are written, and has brought many ambiguities (due to wording, etc.) to the surface. To view this branch you will have to run it locally. Honestly, I'm very happy with the results of this work towards a solid v1 of all specs. I'll also ping you when I remove the WIP status.

[roll]

So based on this approach and if I've got it right datapackage.json should be changed e.g. from this:

resources:
  - name: name1
    schema: {...}
    data: [...]
  - name: name2
    schema: {...}
    data: [...]

to

resources:
  - name: name1
    schema: #schema-ref1
    data: [#data-ref2]
  - name: name2
    schema: #schema-ref2
    data: [#data-ref2]
schemas:
  schema1: {...}
  schema2: {...}
data:
  data1: {...}
  data2: {...}

I suppose it's good for JSONSchema purity and for implementations but it looks like we're making datapackage non manual editable - consider 10 resources long datapackage where to change one resource you need to edit file in 3 different places. It could lead to many errors people unwillingness to working on it by hands.

Also a descriptor for a single resource should look like this?

name: name
schema: #real-schema
data: [#real-data]
real-schema: {...}
real-data: {...}

Or I've got it wrong..

@pwalsh @rufuspollock

[pwalsh]

@roll sorry I'm a bit confused by the above, and how it is JSON Schema-specific?

I think you are focused specifically on the JSON Pointer support, which is new, but does not replace normal URL and file path support. i.e.: schema works just like it always has, and data works just like the proposal for path was destined too - we've just removed the direct inlining of data on the data property, directly to solve issues we talked about in #336 and something that I also thought you were supporting in terms of simplifying implementations ( cf. #336 (comment) )

[roll]

So schema is still inlinable?

upd.
My bad missed that this PR closed ohh (also has wrong understanding of schema thing)

[pwalsh]

@roll yes.