DataTypes Comments Section 1

Editorial Comments on DataTypes Abstract Specification V2.0 Rev 5699

Ballot Preface

• 1.1 Notes to Readers
  • In general, these paragraphs are undecipherable to an outsider. We assume that they will be removed in the final copy?
• 1.2 Acknowledgements
  • • OK
• 1.3 Changes made to this Specification
  • Again, these will be going away in the final document?

1 Overview

• 1.1 Introduction and Scope
  1. P3 - ...intended to implemented directly or solely based on the details.
     • insert "directly" or "solely"
  2. P4 What is a "payload"?
     • suggest "information that should be represented explicitly and the information that should be derived from an explicit representation."
  3. RMO-ODP reference won't be obvious to everyone. Recommend an external reference (http://www.rm-odp.net/ for general and a short statement about the "external" and "computational" views are.
     • Agree-JL
• 1.2 What is a Data Type?
  1. P1 - This introduction starts on the premise that the readers clearly and correctly understand what a data element is. I'm not certain that this is true. Is each bit in this html stream a data element? Is the entire page? Would it make sense to borrow some basic introductory material from ISO 11179 here?
     • 3.3.8 data element - unit of data for which the definition, identification, representation and permissible values are specified by a set of attributes. (ISO/IEC 11179-1 Second edition 2004-09-14).
     • I think that with the audience defined, we may be able to let this go--or at least specify that that these types are designed for the data elements defined in the RIM--JL
  2. P2 - Since we only make use of extensional definitions in one rather trivial case (boolean), perhaps all this detail isn't necessary?
     • Agree--JL
  3. P3 - "A semantic property of a data type is referred to by a name and can be evaluated for any value of a data type."
     • I'm not sure that the notion of "semantic property" makes a lot of sense. As contrasted to, say syntactic property? Perhaps we need to focus on what a property is in general. It is mentioned in P2, but perhaps it needs to be expanded. The term semantic <x> appears at various points throughout this document without adding much in the line of clarity. I would advocate striking "semantic" unless it clarifies the intended meaning.
     • Agree--the term doesn't seem to make a distinction. If there is one, it should be explained.
  4. P4
     • ... construct any> higher order meanings: messages, computerized patient record documents, or business objects and their transactions
     • Neither identity nor state nor changinge of state is defined for a data value. Conversely iIn business objects, documents, and messages, we track state...
• 1.3 Representation of Data Values
  1. P2
     • ...are can be defined - intensionally - ... (why the hyphens?)
       • Remove hyphens
     • Are cardinal numbers defined as a data type?
     • How about "For example, a data type for cardinal numbers (non-negative integers) can be defined as the combination of a successor function, which yields the successor for any given cardinal number plus the rule that zero is the cardinal number that is not the successor for any other cardinal value. We can use this definition...
       • Or use Integer rather than Cardinal
  2. P3
     • ...the Bboolean data type can be defined extensionally, with two distinct values.
     • As the boolean data type turns out to be the only case of an extensional definition, I wonder whether it is necessary to go into this much detail at the abstract level. Is there an intent to use extensional definitions for other types? I suppose that some of the CD work could be viewed as a quasi-extensional approach...
       • Removing this text may help readers focus on more critical concepts, though I don't believe it's really problematic. JL
• 1.4 Properties of Data Values
  1. P1
     • going seriously passive here - how about "Data types specify the properties of data values."
       • Agreed JL
     • Are units really the most common example?
       • The hyphen characters are a bit messed up. In order to avoid the confusion in the above remark, I suggest "The fields of composite data types — e.g. the units property of a measurement — are an obvious example of such properties."
     • However, more generally one should think of... --> Generally, however, one should view ...
  2. P2 value set isn't defined - it needs at least a brief reference.
     • Perhaps just a link to the glossary--we don't want to distract from the topic at hand. More seriously, the sentence "The domain of a property may be a subset of the data type's value set, since other constraints may be applied to the data type in the context of the property" is misleading, as it posits a connection between the value set for a specific property and the value set for the data type. It's true, they might be the same, or related by subsetting, but such a relationship would be entirely fortuitous. Delete the sentence. Use instead an example.
  3. P4 "Whether semantic properties..." - How do these relate to the general properties that were described in the previous paragraph? (Recommend striking "semantic").
  4. P7 The use of semantics is ok here, as we're not referring to semantic types or semantic properties.

1. • In general, this section needs some work - expanding and polishing, but it is getting close. It plays a key role in the comprehensibility of the whole document and it is important to get it right...

• Need for Abstraction
  1. P1 "... version 3 is its openness towardsneutrality regarding representation and implementation technologies. . All HL7 version 3 specifications are supposed to be done in a form independent from specific representation and implementation technologiesrequired to be technology and representationally neutral.
  2. Why is this specification so circular
  3. The properties of ANY all have each has a type that . . .
  4. . . . specifications to best resolve.
  5. GENERAL Some of these questions make no sense until you've read the rest of the spec. If you are going to introduce ANY in the introductory material, you need more explanation.
     • Or at least a reference (q.v.).
  6. Q3 P1 With a semantic specification, an Implementable Technology Specification (ITS) can conform simply by asserting a mapping between the constructs of its technology and the HL7 version 3 data type semantics.An Implementable Technology Specification (ITS) conforms to an abstract specification by asserting a mapping between the constructs of its technology and the properties defined in the HL7 version 3 abstract data types.
• 1.6 Need for an HL7 Data Type Standard
  1. P2 - For example, fFew implementation technologies...
  2. P3 - join w/ P2.
• 1.7 Overview of Data Types
  • Foundation
    1. NULL comment on BL a bit out of place, but it passes.
    2. COMP and CEQ seem out of place. In addition, is CEQ abstract as well?
       • these are complex, but I'm not sure there's a way around that
  • Basic
    1. Instead of the data, an ED may contain only a reference - This needs clarification.
       • "An ED may contain a reference to a value rather than the value itself."
    2. Note that ST is a specialization of ED where the mediaType is fixed to text/plain and several other properties are constrained to null. - out of place - this goes with the next entry as a second sentence. ST is a specialization of ED ...
    3. that optionally may - That may optionally . . .
    4. CD - this needs redefinition - the definition is not correct and is unnecessarily inflammatory
       • comment not clear: JL
    5. CO - Coded dataA Concept Descriptor where an ordering relation is defined among some or all of the concept codes. Numerical value has *nothing* to do with this. This is implementation specific.
    6. CS - Coded data where all the fields are predetermined with the exception of the code.
    7. TEL - is this a URI or a URL? Is URL implementation specific?
    8. EN is underspecified, but will pass
  • Quantities
    1. PQ - how does this align with the previous 3? - Are INT, REAL and RTO all quantities if so, it would be good to stress this, so we understand that PQ takes one of these and adds dimension.
       • But current statement includes this stipulation: stet
    2. EXPR - does this belong in Quantity? it may be stand-alone
  • Quantity Collections
    1. expressional is a wierd word - does it mean expression?
       • the term can be deleted
    2. "Term" is capitalized and used without definitions.
       • remove "Term"? "An expression that builds a QSET from a union of other QSETs," etc.?
    3. QSD and QSP need to be differentiated
    4. QSC - need more detail.
    5. IVL - same
       • looks ok to me--JL

• • Uncertaintities
    1. What is a "generic data type extension"
    2. "used to specify"? - That specifies?
       • Use the same construction for both entries, UVP & PPD.
    3. " (§ ) are not fully qualified types, but only restrictions on previously defined types and flavors." - what is this? What does it reference...
       • "Flavors"

• • Flavors
    1. Something is missing here - shouldn't there be an introductory paragraph of some sort? The paragraph needs to mention that the meaning of the constraints will be clarified by looking at each individual type.
       • A gray bar, as previously, may provide context for the short intro.
    2. ED.DOC.INLINE so the contents are a document is not provided by means ofrather than a reference.
    3. ED.DOC.REF - so that the contents are a reference to a document."
    4. TEL.URL - didn't the definition of "TEL" say it had to be a URL?
       • That seems to have been a typo
    5. PN, ... - why are Entity and Person capitalized? Maybe explain in the introductory material? I would rather see lower case.
       • Class names tend to be capitalized in the RIM.
    6. IVL.LOW, IVL.HIGH, IVL.WIDTH, ... - not a semantic explanation. Replace lowClosed with what it means.
    7. GTS.BOUNDEDPIVL - This needs to be restated in English.
• 1.8 Conformance
  1. GENERAL Should there be an introductory paragraph that grounds the meaning of "SHALL", "MAY" and any other critical keyword?
  2. All instances of these data types SHALL be valid with respect to the invariant statements contained in this specification.
  3. QUESTION: Is it up to the creator or the recipient to make sure this is true? The second sentence weakly implies the creator, but it isn't absolutely clear.
     • Seems clear to me. JL.
  4. . . . types SHALL be valid with . . .
  5. "Definition 1" - This isn't a definition - this is a systemic problem throughout this document and needs to be corrected.
     • In this case, it can be 'example.' In the case of the specifications, DTDL statements are divided between declarations and constraints, which may be more descriptive titles.

• 1.8.1 Constraining Model
  1. GENERAL Need a bit more detail.
  2. Generally, . . . (insert comma) . . . as the types of RIM attributes (plural)
  3. P1 Don't capitalize "Contstraining Model"
  4. P2 The intent of this paragraph isn't clear - are null flavors outside the scope of constraining models? Is there any way that a constraining model can declare that it doesn't allow a null flavor in a given data value? This tends to imply not, which I don't think is what is intended.
  5. P3
     • NI - need to spell this out - we don't know what it means at this point in the document.
     • Where did "*" come in on cardinalities - did we intend to add "0..*" and 1..*"? If not, what goes on. What does "Cardinality of 1" mean with respect to what was just stated. Wouldn't this be more simply put in terms of min and max cardinality?
     • P4 Recommend moving these to after paragraph 2.
     • GENERAL - I think that this section could do for some work. There are some important concepts in here (optionality, cardinality, null flavor) that need to be clearly understood.