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 6: | Line 6: | ||
* Turn II.scope into a mandatory attribute [[User:Rene spronk|Rene spronk]] | * Turn II.scope into a mandatory attribute [[User:Rene spronk|Rene spronk]] | ||
** In MnM we discussed this and there are issues about making something mandatory that may be populated unsafely (Lloyd). | ** 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 | + | ** 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) | * 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" | ** 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) | * 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". | ** 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) | * 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 | ** 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. | ||
Revision as of 16:13, 19 January 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)
- 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.
