This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Data Types R3 issues"

From HL7Wiki
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