Closed timgdavies closed 12 months 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.
In my previous comment and issue asked if all ids are UUIDs as suggested by And
However this is contradicted here,
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.
Closing as this has been fixed in 3.0 (at the latest!)
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
instead of
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: