Should the admin observableproperty rename page also update validproceduretime.descriptionxml?

[srstsavage]

Currently the admin observableproperty rename operation updates the observableproperty identifier but doesn't take into account references to those identifiers in SensorML contained in validproceduretime.descriptionxml. I think it would be a good idea to also update references to the observable property being renamed in SensorML. Thoughts?

[CarstenHollmann]

Another option would be to send an UpdateSensorDescription with the correct observable property references to the SOS.

If you want to update the sensor description in validproceduretime.descriptionxml you have to take into account that there may exist multiple descriptions for the same procedure. Should the observable property references be updated in all descriptions or only in the last?

And how to deal with other procedure description formats? If further procedure description formats would are supported in the future, the observable property references update should be supported for them.

Probably the easiest solution would be a string replacement and it would work for other procedure description formats other than SML.

[srstsavage]

Good point, I hadn't considered old SML versions. I would think that you'd want to update all of them, since you're changing the identity of the same observable property throughout.

A string replacement seems logical in order to support non-SML formats. However, if a user had previously named an observable property "test" or "property" or something similar a replacement could have unintended results. Maybe offering checkboxes with these options selected by default ("update observable property in procedure descriptions" and "update observable property in old procedure descriptions") would be appropriate?

[CarstenHollmann]

I agree with you that the string replacement could be probelmatic but is the simplest solution to support non-SML formats. Another solution would be to implement a "ProcedureDescriptionObservablePropertyReplacer" logic with repository, replacer, key (format), and ServiceLoader, similar to the decoder, encoder, etc. If a new non-SML format is supported/implemented, a corresponding replacer can be implemented.

Your suggestion with the checkboxes sounds great.