Datatypes R2 Issue 67

Need to document what the acceptable substitution rules are for datatypes.

Outcome of discussion in R2 datatypes taskforce: YES, this needs to be documented. But it is not the concern of the datatypes. The datatypes define a number of possible substitution methods, it is up to MnM and conformance through the HDF and the Refinement, Constraint, and Localisation (RCL) standard to control how this works in V3 modeling. It will not be documented in the data types. A table based on the one below was provided to Conformance for RCL. As an R2 issue, this is closed, though there is still some useful content in this page.--GrahameGrieve 21:24, 20 June 2007 (CDT)

See MNM hot topic Datatype Substitution Issues for further discussion.

This table summarizes the allowable datatype substitutions in designs.

There are two circumstances when one would constrain datatypes:

1. Modelling-time: as part of the HDF, done by committee or affilliate
2. Run time: as part of the on the wire format (uses xsi:type) as a constraint of a datatype as used in the serialized model (mostly: the message type)

Relationship to Conformance

Conformance discusses constraints, this is about specialisation. Constraints may be applied without specialisation. to complete this section and discuss with Conformance.

Run-time dataype substitution

• ANY can be substitutioned as below

Template datatype Substitution

This is an open question. Every allowed substitution is also a valid constraint (in the template sense) on the datatype for which it is a substitution. So the template could make the datatype substitution and implementations for templates would have to render the substitution as a constraint.

• GTS

I've got an R-MIM that has GTS in it (see the ActReference R-MIMs in shared messages) since they reference (are an extract of, a summary of) any random act. This requires run-time subtitution. According to Grahame GTS should not be in the above list, in which case I'd have to change the models to use ANY for effectiveTime and constrain the runtime substitution somehow. I dont really want to do that. Rene spronk 06:45, 14 September 2006 (CDT)

Right. That's an interesting issue. Why does it require run time substitution - what are you thinking this will achieve? And you can't change to ANY

At modelling time I won't know what specilaization of GTS has been used in Acts that I'll be referencing. As such I have to allow for all GTS specializations. The acts I'm referencing are based on various R-MIMs, each may have used a different GTS speclilization at modelling-time. Rene spronk 07:37, 14 September 2006 (CDT)

Modelling time datatype substitution

Note that regards to collections, COLL<X> can be substituted with COLL<Y> where Y is a valid constraint on X. Note also the committees can introduce Mixins (UVL, and NPPD) in the models to any attribute (if they make sense)

The second table is those proposed by Lloyd, but they have no formal basis in the abstract datatypes:

Todo - can | IVL<TS> substitute for PIVL<T>?

Additional Issues

You may move that somewhere else if you wish, but it's experience I have from implementing it in JavaSIG. Gschadow 22:34, 11 January 2007 (CST)

There is more issues for consideration. When I parse Observation.value I am in trouble. It is defined as ANY, and what I might receive is:

<observation ...>
  ...
  <value xsi:type="CV" code="a" codeSystem="1.2.3.4" displayName="Ay"/>
  <value xsi:type="CV" code="b" codeSystem="1.2.3.4" displayName="Bee"/>
  <value xsi:type="CV" code="c" codeSystem="1.2.3.4" displayName="Cee"/>
  <value xsi:type="CV" code="a" codeSystem="1.2.3.4" displayName="Ah"/>
  ...
</observation>

What will I do with that? How do I know if it is a SET, LIST, or BAG? It's important, because as a SET it would have cardinality 3 (not 4) while the list and bag would have size 4. But the bag could put both a-s together.

I think that for the XML ITS we consistently need to define "item" types:

• List item: LXIT<T> extends T
• Bag item: BXIT<T> extends T add attribute number, so you can stick multiple of the same items into one XML element.
• Set item: SXIT<T> extends T

Only if we do this consistently can anyone read the repeated Observation value unambiguously.

Thanks. Gschadow 22:34, 11 January 2007 (CST)

Proposed Constraint Rules

--Lmckenzi 21:51, 6 January 2008 (CST) The following is a set of rules intended to identify what sorts of constraints can legally be made as part of the model refinement process (RIM->D-MIM->R-MIM->etc.). The intention is for the rules to be evaluatable against a MIF representation of the universal datatypes as well as locally defined flavors.

0. Protected and private types are not exposed in constraint rules

 Rationale: Protected and Private types cannot be referenced as the types of attributes or datatype properties

1. An abstract class may be "constrained" to any of its abstract children or concrete descendants

 Rationale: Standard substitution of an abstract class for its specializations

2. A concrete class may be "constrained" to any descendant that adds no non-operation properties not derivable in the parent

 Rationale: Specializations that constrain are obviously constraints (E.g. from ED to ST)

3. A concrete class that adds non-operation properties not derivable from its parent may be constrained to its parent

 Rationale: Specializations that extend are extensions (E.g. from SC to ST)

4. For the purpose of the above, bindings of a generic type are considered "descendants" of the generic type

5. For types that have dual inheritance, constraint from one of the parents to the child may only occur if there are no non-derivable non-operation properties inherited from the other parent

6. Types may be constrained to flavors derived from them

7. A type that has a promotion from a particular type can be constrained to the promoted type

 E.g. Can constrain from REAL to INT

8. A type that has a demotion to a type can be constrained to that type

 E.g. Can constrain from PQ to REAL

9. Constrainability is transitive (If A can constrain to B and B can constrain to C, then A can constrain to C)

10. Types can also be extended to include mixins

 E.g. To allow PQ to be replaced with URG<PQ>

11. Flavors of a type that has a promotion can also be constrained to the promoted type

 E.g. To allow PN to constrain to ST just as EN constrains to ST

Issues:

- Rules #2 and #3 depend on the idea of distinguishing derivable from non-derivable properties. These are not currently labeled in the spec and there is some controversy of making these distinctions as there are some properties that could go either way (e.g. the "sometimes derivable" properties of IVL).

- Rule #3 means that constraint substitution would differ from standard object substitution rules, though given that this happens at design time should theoretically be less of an issue.

Source	Allowed
ANY	anything (including mixins)
BL	nothing
BN	nothing
ED	ST, UID
ST	UID
CD	CE, CV, CO
CE	CV, CO
CV	CO
CO	nothing
CS	nothing
CR	nothing
SC	ST - R2 proposal: add a demotion to support this.
II	nothing
TEL	nothing
AD	nothing
EN	PN, ON, TN
PN	TN - R2 Proposal for demotion
TN	nothing
ON	TN - R2 Proposal for demotion
QTY	TS, MO, REAL, INT, TS, RTO<QTY, QTY>, PQ
INT	nothing
REAL	INT
RTO	nothing
PQ	nothing. Since substituting REAL is not the same as fixing the value of unit to a unitless measure (unit="1"), this is not a safe thing to do. We advise the use of data type constraints to fix the unit to "1". Why? Gschadow 22:11, 11 January 2007 (CST)
PQR	nothing
MO	nothing
TS	nothing
SET<T>	T and substitutions of T. We have asked MnM to clarify the implication of substituting a T for a SET<T> in a model with regards to nullFlavor.
LIST<T>	SLIST<T>, GLIST<T>, single T and substitutions of T
GLIST<T>	T and substitutions of T
SLIST<T>	T and substitutions of T
BAG<T>	T and substitutions of T
IVL<T>	T and substitutions of T
HIST<T>	HXIT<T>, T and substitutions of T
UVP<T>	T and substitutions of T
NPPD<T>	T and substitutions of T
PIVL<T>	nothing
EIVL<T>	nothing
GTS<T>	SET<PIVL<TS>>, SET<EIVL<TS>> There is not GTS<T>. GTS := SET<TS>. What's a "SET<PIVL<TS>>"? Don't even go there. You probably mean a term involving only PIVL<TS>. And what about one PIVL<TS> intersected with an IVL<TS>? Gschadow 22:11, 11 January 2007 (CST)
PPD<T>	?