Exceptions to immutability

[jpmckinney]

From #475 (comment)

tiredpixel: how can something like a clerical error be distinguished from an actual change?

@jpmckinney: This can be handled in different ways, depending on user needs.

As you suggest, the simplest is to just change the original data. This breaks immutability – but, honestly, unless there are very strong use cases for preserving immutability, then it is so much simpler (for both users and publishers) to allow clerical errors as an exception to immutability.

Another option: Today's procurement systems follow the same structure as their original paper processes. So, a notice is published, containing a clerical error. Being a physical paper posted on notice boards and distributed to offices, it's not possible to simply change it. As such, the EU, for example, publishes a special type of notice ("Corrigendum", or "Change" more recently) with such changes. Publishers are not allowed to make non-clerical changes via such notices. In BODS, perhaps a new field on a statement would serve as a flag, like "correction": true.

@kd-ods: Yes - we will need to treat certain types of correction and post-hoc redaction as special cases. So we will be outlining in future versions of the standard the circumstances under which statements need not be immutable.

Emphasis added. Opening the issue as otherwise this intention for future BODS versions is untracked.

[StephenAbbott]

Thanks @jpmckinney. The BODS team is gearing up to the release of version 0.4 in June and will be spending the next couple of months documenting all the outstanding feedback we received where new issues need to be raised to capture future development possibilities. We have internal logs of some feedback which will be raised as issues where relevant on the BODS Github repo

[jpmckinney]

Thanks, @StephenAbbott. Maybe a process change to consider is to record suggestions and discussion in this issue tracker, rather than in an internal tracker. Open standards typically record everything in their public tracker – especially if the suggestion or discussion already previously occurred in that same public tracker. While going through past issue, you also noted renaming had been recorded internally, but this should just be noted here, in this tracker.