cportele
commented
1 year ago If you would like to keep the voidable stereotype, then I think we can keep it.
I do not argue with the use case, this is exactly why I proposed the stereotype in INSPIRE where it was considered important to distinguish whether an attribute was not captured or was known to have no value. This was because of the provisions in the Directive that all information in the original dataset needs to be provided, but there is no obligation to capture information that is not part of the original dataset.
In hindsight, it wasn't a great idea.
- While there are ways to encode the difference in XML and JSON, it is hard to implement in other technologies, notably relational DBMSs and will result in more complex implementations. And while there are ways to represent a null/nil/void value in XML/JSON vs an absent property, this would only be a community convention, not something that is explicitly specified in the XML or JSON specs; depending on the libraries used, serializing and deserializing the difference into an object representation properly may not be trivial. As a result, implementations to store, manage and publish data become more complex and in almost all cases tools need customization.
- I am not aware of client software that differentiates between a null/nil/void value and a missing value. As a result, client applications will typically be custom developments.
- While I think that the semantic difference should be pretty clear, many have struggled with understanding it. It was and is very hard to communicate. I have been asked questions about voidable so many times in INSPIRE.
So, it can be done, but I would only use the concept for cases which target only (a few) expert users and when the distinction is really important; that is, you can ensure that the concept is understood and you can justify the extra effort and cost. I would not use it in data that is intended to be used by many users.
Also, as discussed in the call, I would not expect that 19103 or 19109 would include such a stereotype. It is a convenience shorthand notation for a union between a null value and some other type, but it breaks the UML metamodel and the result is a model that is not using UML, but a custom metamodel.
PalmJanssen
About the voidable construct.
The intention as I understood was to leave out the voidable construct because the use and interpretation of the \<\<voidable>> stereotype is net very well understood. It is also not part of the 19103 or 19109.
However I do think it is a valuable construct that is needed and fills a gap between the semantically correctly described reality and its sometimes omited registration into data.
My points are these:
An example is this. A Pipeline has two properties of interest one being diameter and one being color. Both attributes have a cardinality of 1 because in reality a pipeline always has a diameter and a color. However in practice both are not always recorded and existing in a registration. How to express that in an application schema? An optional 0..1 cardinality would violate the semantics of reality. A cardinality of 1 would not always be consistent with the registration.
So when we consider an application schema as a model of reality and not of a registration the voidable construct is needed.
I would also advocate to bring it into 19103 or 19109