Data Types R3 issues

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)
  • Ideally we should have representations at Conceptual, Logical and Physical. We've never done Conceptual before.
• 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. (Lloyd)
• 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? (Lloyd)
• Get schemas to enforce datatype flavors, use of mix-ins, etc. Possibly use Schematron w/ schema-aware X-paths? (Lloyd)
• Add note to integrity Check about it's utility with digital signatures (Grahame)
• Add ability to flag lists as unsorted. (Lloyd)
  • A list nominally has a sort order. And sometimes the model is constrained to require the data to be a list. However, on occasion the order won't actually be known. This is sort of declaring a null flavor about the list. I.e. It's not a fully valid list, but you've still got some useful data to transmit.
• PIVL is unable to express that an interval starts at a time relative to another event. You can specify a particular starting date, or not starting date. But that's not often what you want, specially in DEF mood - start taking this tablet 3 times a day 2 days after some other event happens (the "after some other event" is not PIVLs business, but the days bit is - in particular, if you need to include the initial offset inside a GTS to operate with some other GTS fragment) (Grahame, for Cecil)
• We don't allow multi-dimensional collections (e.g. lists of lists of lists). There are some observation types where this would be extremely useful. At the moment, we need to separate observations for each occurrence, and that's exceptionally inefficient (Lloyd)