openreferral / specification

The Human Services Data Specification - a data exchange format developed by the Open Referral Initiative
https://openreferral.org
Other
117 stars 50 forks source link

Bug: fields are missing unique:true constraint in data-package.json #199

Closed timgdavies closed 12 months ago

timgdavies commented 6 years ago

Most id fields in datapackage.json are described with the text "Each X must have a unique identifier".

However, in most cases, this is not properly declared in datapackage.json which contains

"constraints": {
   "required":true,
}

instead of

"constraints": {
     "required":true,
     "unique":true
}

There is a question in this case of whether the schema or the description text should be treated as authoritative, but I would consider the intent of the field to be clear (ids MUST be unique) but that the constraint has not been properly enforced by the schema.

This feeds through into the documentation which is generated from the schema and presents:

image

timgdavies commented 6 years ago

I've committed a fix to branch 199-unique-fields (see diff against master here).

You can also preview the docs as they appear for this branch at http://docs.openreferral.org/en/199-unique-fields/hsds/reference/#service_area

As this is a bug-fix that could affect users who are using datapackage.json to validate their data, I would suggest it should form a 1.1.1 bug fix release, and should have at least a two week comment period.

There may also be knock on effects to the API specification schema to be considered if @kinlane's work carried this bug forward into the API Spec. I've not checked on this yet.


The alternative work-around for this issue, if the schema 'bug' (i.e. weaker validation than the normative descriptions state) is left in until a next version because it would affect current adopters, would be that we drop the 'Unique?' column from the documentation display, and rely on the prose to cover this.

japrogramer commented 4 years ago

In my previous comment and issue asked if all ids are UUIDs as suggested by image And image

However this is contradicted here, image

what are overlapping identifiers? adding a prefix to a uuid defeats the purpose of a uuid in my opinion. perhaps that prefix needs to be stored in a separate field.

mrshll1001 commented 12 months ago

Closing as this has been fixed in 3.0 (at the latest!)