Remove datapackage reference from jsontableschema foreign keys for v1?

[roll]

Overview

For now jsontableschema contains cyclic-link with datapackage specification - http://specs.frictionlessdata.io/json-table-schema/#foreign-keys - to allow cross datapackage linking.

Pros

• allow general referencing mechanism (somewhere in the internet)

Cons

• allow general referencing mechanism instead of focusing on data integrity inside the data package
• no implementations for now and hard to say when it could be done and on which level (jts-dp)
• low-level knows about a top-level (abstraction break) reducing light-weighting of jsontableschema spec

Proposed

Wording of changes is bad but I suppose enough to show the idea:

A foreign key is a reference where entries in a given field (or fields) on this table is a reference to an entry in a field (or fields) on a separate resource. This specification delegates the definition of a separate resource to implementations and high-level specifications. E.g. the datapackage specification use it for a datapackage resource referencing.

The foreignKeys property, if present, MUST be an Array. Each entry in the array must be a foreignKey. A foreignKey MUST be a Hash and:

• MUST have a property fields. fields is a string or array specifying the field or fields on this resource that form the source part of the foreign key. The structure of the string or array is as per primaryKey above.
• MUST have a property reference which MUST be a Hash. The Hash
  • MUST have a property resource which is the name of the destination resource. For self-referencing foreign keys, the value of resource MUST be "self".
  • MUST have a property fields which is a string if the outer fields is a string, else an array of the same length as the outer fields, describing the field (or fields) references on the destination resource. The structure of the string or array is as per primaryKey above.

Links

Here is a full discussion - #297

[roll]

@pwalsh
Version-1 candidate in implementation mind.

[rufuspollock]

@roll can you highlight the diff here vs current spec.

I agree the cyclic reference is not great. The general wording of this section as it currently stands is not as clear as i would like.

Re datapackage in FKs: I have seen zero examples of cross data package references in the wild. (And if they did happen they might be better stored outside of the data package in a separate file). As such we could drop the datapackage option on FKs without any issues for now.

[roll]

Green note should be rewritten.

...

MUST have a property reference which MUST be a Hash. The Hash:

• MAY have a property datapackage. This property is a string being a url pointing to a Data Package or is the name of a datapackage. If absent the implication is that this is a reference to a resource within the current data package or this is self-referencing foreign key.
• MUST have a property resource which is the name of the tartget resource within the referenced data package (e.g. resoure inside datapackage). For self-referencing foreign keys, the value of resource MUST be self.

---

I have some troubles with wording here but the main idea I suppose should be - allow jts to use self referencing and allow jts to use abstract resource referencing. Wich will be described on datapackage level or in other top-level specifications. So it will decouple this too specs.

[pwalsh]

Depends on #327 for proper reframing of this.

[pwalsh]

Implementing JSON References will solve this issue completely. #325 (comment)

[rufuspollock]

I actually suggest we remove foreign key references across Data Packages.

[pwalsh]

will close with #337

[pwalsh]

We won't merge #337 until we can support all the changes in the core implementations we maintain. So closing this as it is implemented in #337 , as leaving it open creates confusion.

[rufuspollock]

FIXED. We removed foreign key references across data packages.