This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Data Types R3 issues"
Jump to navigation
Jump to search
Line 18: | Line 18: | ||
* 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) | * 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) | * 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 |
Revision as of 02:29, 2 February 2011
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