Make Observation mutation support optional

[selimnairb]

There are use cases where individual Observations will not/should not change once they are made. For example, raw PM2.5 data from an air quality sensor. The raw data, once observed, will not change. If QA/QC procedures are applied, they should be applied to Observations stored in new Datastream. Being able to mutate observations means allows for Observations to be changed without a trace, which is problematic (e.g. in use cases related to environmental standard compliance).

[hylkevds]

One viewpoint could be that this falls under access control, and is thus outside of the scope of the specification. It's possible to restrict PUT/POST access to Observations. The question then becomes, does the conformance test apply to a service with added authentication/authorisation? Personally I think it doesn't.

[selimnairb]

I understand your logic here. If we do decide on this course, we should include guidance in the spec that the conformance tests do not apply when auth/authz is enabled. I’d be happy to draft such language if need be.

[KathiSchleidt]

tricky call, as it is fairly specific (though also common ;) ) Is there a way to restrict access per DataStream? From my memory, STA tends to depend on the unterlying TomCat access modalities, so allowing POST for specific IPs, but not on the datastream level I think what we'd really need here is a way of defining a datastream as write once, read mostly (and either hang yourself or go into hard-core admin mode if you really do make a mistake in the primary data)

[taniakhalafbeigi]

I agree with @selimnairb on this and I think we can make Observation entity immutable. And as he mentioned, any QA/QC can happen in another Datastream.