Difference between revisions of "Datatypes R2 Issue 67"
(→Additional Issues: moving down) |
(Moving additional issues down) |
||
Line 132: | Line 132: | ||
|- | |- | ||
|-} | |-} | ||
+ | |||
+ | |||
+ | == Additional Issues == | ||
+ | |||
+ | You may move that somewhere else if you wish, but it's experience I have from implementing it in JavaSIG. [[User:Gschadow|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. [[User:Gschadow|Gschadow]] 22:34, 11 January 2007 (CST) |
Revision as of 04:37, 12 January 2007
Need to document what the acceptable substitution rules are for datatypes.
This table summarizes the allowable datatype substitutions in designs.
There are two circumstances when one would constrain datatypes:
- Modelling-time: as part of the HDF, done by committee or affilliate
- 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)
Contents
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)
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".
|
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>>
|
PPD<T> | ? |