This wiki has undergone a migration to Confluence found Here
Data Types R3 issues
Jump to navigation
Jump to search
This is the register of known data types issues for release 3.
For now, just enter the change proposal as a single point in the list, with your name
- Collapse Abstract and ISO 21090 into a single specification partitioned according to SAIF (Grahame)
- Turn II.scope into a mandatory attribute Rene spronk
- In MnM we discussed this and there are issues about making something mandatory that may be populated unsafely (Lloyd).
- In general anything mandatory is a nuisance for implementers and may be populated quickly, dirty and/or unsafely. As such Lloyds argument applies to all mandatory model elements. Given the importance of II.scope to determine object equivalence there are IMHO sufficient reasons to consider turning this into a mandatory attribute. It's a tradeoff between the chances of unsafe use, and having to deal with a heap of implementation issues that we're facing without II.scope being present. (Rene)
- Add 'conformance' into datatype properties (Lloyd)
- introducing idea of "conformance" (required, optional, not permitted) into the datatype properties. E.g. "You are conformant if you ignore displayName, but not if you ignore code"
- Encompasses issues deferred by Datatypes R2 Issue 103
- Introduce idea of "implementation" or "closed community" constraints on datatypes (Lloyd) (but initiated by Grahame)
- implementers to be able to do things like constrain out the root when it's known. I.e. "non-worst case interoperability".
- Fix problems with cardinality in collections, likely by treating cardinality as an "argument" to the collection (Lloyd)
- If you have a DSET<II>, cardinality of the attribute is still really 0..1, but the DSET may have a constraint that says number of items must be 2..5. Could be handled as DSET(II,2,5). Would require changes on the model sides too
- Allow address parts to nest. Makes it possible to send fully encoded address parts and receiver can parse the levels they know/care about and ignore further encoding. Could theoretically be relevant to names too, though less important there.
- Provide specific guidance about how to declare constraints on mixin attributes in a UML type declaration. I.e. How do you say that expressions are or are not allowed in a QTY datatype for a particular attribute in a UML model?