DataTypes Comments Section 4

4 Basic Types

• 4.1 Binary Data (BIN) specializes LIST<BN>
  1. "a character-based ITS SHOULD NOT convert character data into arbitrary binary data and then represent binary data in a character encoding." - what does this mean? Maybe an example is called for?
• 4.2 Encapsulated Data (ED) specializes ANY
  1. "Note that ST is a specialization of ED where the mediaType is fixed to text/plain and several other properties are constrained to null." - this seems oddly out of place...
• 4.3 Character String (ST) specializes ED
  1. data - "Operations may be performed directly upon the binary content by using data." - I'm not sure what sort of operations are being suggested, but here is a place where it needs to be stressed that content is identity. If you alter the content of the data portion of an ED, (assuming I understand the section on identity correctly), you have a different ED.
  2. reference -
     • Type: TEL.URL - "A telecommunication address (TEL), such as a URL... - isn't it more than such as the definition says that it is.
     • "... a URL for HTTP or FTP" - I'm not sure what a URL for HTTP would look like. I would propose the following: "A URL that resolves to binary content of the ED." (I don't get "that could as well have been...")
  3. integrityCheck - "The integrity check is a shortA binary value containing a cryptographically strongsome form of a checksum that iscalculated over the data." - It doesn't have to be "cryptographically strong", whatever that means, or be calculated of strictly binary data. "Short" is a strictly subjective term and has no meaning...
  4. translation - "Translations SHALL not contain translations." - is this stated verbally to keep from having to come up with a specialized, non-translated ED?
  5. 4.2.1 P1 - ED acts as a wrapper of binary content content - ???
  6. Definition 105 is curious, especially as the sentence following it appears to contradict it. It would seem that either (a) the reference is opaque (e.g. an ITS issue) and the ED always returns data of (b) the reference is visible and the retrieval of the actual information is done by the client application. I don't understand the situation described here.
  7. Table 14 - heading is messily rendered.
  8. Tables of recommended media types - especially based on someone's determination of the relative security and ability to propagate viruses seems to be pushing the "abstract" nature of this spec...
  9. "There is a risk that general SGML/XML is too powerful to allow a sharing of general SGML/XML documents between different applications. " - gosh, then what is HL7 going to use instead?
  10. What are the invariants with respect to binary compliance to the media type. If, for instance, an XML document isn't well formed, is there anything that needs to be said or done?
  11. Table 15 - heading is messily rendered.
  12. 4.2.6 Reference Definition: "A telecommunication address (TEL), such as a URL for HTTP or FTP, which will resolve to precisely the same binary data that could as well have been provided as inline data." (See comment on this topic above.
  13. The reference SHALL point to the same data as provided inline. It is an error if the data resolved through the reference does not match either the integrity check, in-line data, or data that had earlier been retrieved through the reference and then cached. - this seems like a strange statement. The intent is to say that it cannot change, but this is a curious way to go about it. If we didn't cache it, then is change ok?
  14. It still isn't clear whether it is the obligation of the data type ITS or the retrieving application to dereference the URL.
  15. 4.2.7 Integrity check. - issues with the definition are discussed earlier in this document.
  16. Is Integrity Check strictly for reference resolution, or does it apply to "inline" data as well?
  17. Are sha-1 and sha-256 the only algorithms that can be used? If so, I withdraw the suggested changes to the definition above...
  18. 4.2.9 - (formatting) - bumps into the preceding table, which is confusing.
• 4.4 Character String with Code (SC) specializes ST
• 4.5 Concept Descriptor (CD) specializes ANY
• 4.6 Coded Ordinal (CO) specializes CD
• 4.7 Coded Simple Value (CS) specializes CV
• 4.8 Unique Identifier String (UID) specializes ST.SIMPLE
• 4.9 ISO Object Identifier (OID) specializes UID
• 4.10 DCE Universal Unique Identifier (UUID) specializes UID
• 4.11 HL7 Reserved Identifier Scheme (RUID) specializes UID
• 4.12 Instance Identifier (II) specializes ANY
• 4.13 Universal Resource Locator (URL) specializes ANY
• 4.14 Telecommunication Address (TEL) specializes URL
• 4.15 Address Part (ADXP) specializes SC.NT
• 4.16 Postal Address (AD) specializes LIST<ADXP>
• 4.17 Entity Name Part (ENXP) specializes SC.NT
• 4.18 Entity Name (EN) specializes LIST<ENXP>