Datatype Substitution Issues

Introduction

INM discussed the datatype substitution rules. A number of issues arose upon which INM wished to seek input from MNM.

T, SET<T>, and nullFlavor

Motion: We would like MnM to clarify the implication of substituting a T for a SET<T> in a model with regards to nullFlavor.

The problem here is that the XML ITS does not have a good way to distinguish between a SET<T> that is null, and a set with one null item. These things look exactly the same in the ITS. We have ruled that a single item with a nullValue is actually to be understood as a SET<T> that is null.

Given that you can change SET<T> to T, it becomes unclear what a single value with a nullFlavor is.

Discussion

Well, Does it really matter? It's really a question of what the receiving application expects to read for the attribute. Although the wire format is the same, the application would probably rather interpret the meaning of the of the xml in terms of what it expects, rather than needing to understand whether the sender tried to substitute T for SET<T>

Resolution

2007-07-06: In constraining a SET to 0..1, we're effectively defining the SET, thus the collection being null isn't meaningful. Thus the null flavor on a 0..1 SET applies to the item in the set. Null already implies "don't know if it even exists", so presence or absense of the set vs. presence or absense of the value in the set becomes synonymous. Motion: Mead, second Lee 4-0-0

BAG -> SET or LIST

Motion: The substitution of SET or LIST for BAG is potentially problematic and we do not support this in data types R2.

The problem is that at the abstract level, LIST and BAG introduce new semantics and do not support some of the semantics of SET - so they are not really acceptable substitutions in abstract. If you ignore the semantic definitions and ignore non-discrete SETs, then you can build LIST and BAG from SET. But is the imposition of the BAG and LIST behaviour actually acceptable.

INM would like MNM to clarify exactly what the intent of allowing these substitutions is.

Discussion

2007-07-06: We need to support BAG, LIST and SET for things like name, address or phone number. Thus the RIM needs to allow us to constrain to any of these three types. We need more information from INM to make the decision about appropriate hierarchy.

PQ -> REAL

Motion: We do not allow REAL to be substituted for PQ. Motion: The change discussed here will apply for datatypes R2.

What happens to the unit if PQ is confined to REAL?

Resolution

2007-07-06: We accept this constraint because the semantics of REAL and PQ are not the same. However, there is a need for a PQ flavor (PQ.REAL) that prohibits unit (which will look like REAL) and another (PQ.INT) that prohibits unit and forces value to be an integer (which will look like INT). Motion: Lee, Second: Austin 4-0-0