DataTypes Comments Section 4

From HL7Wiki
Revision as of 23:16, 8 March 2008 by Hsolbrig (talk | contribs)
Jump to navigation Jump to search

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...
    2. 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.
    3. 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...")
    4. 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...
    5. translation - "Translations SHALL not contain translations." - is this stated verbally to keep from having to come up with a specialized, non-translated ED?
    6. 4.2.1 P1 - ED acts as a wrapper of binary content content - ???
    7. 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.
    8. Table 14 - heading is messily rendered.
    9. 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...
    10. "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?
    11. 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?
    12. Table 15 - heading is messily rendered.
    13. 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.
    14. 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?
    15. It still isn't clear whether it is the obligation of the data type ITS or the retrieving application to dereference the URL.
    16. 4.2.7 Integrity check. - issues with the definition are discussed earlier in this document.
    17. Is Integrity Check strictly for reference resolution, or does it apply to "inline" data as well?
    18. Are sha-1 and sha-256 the only algorithms that can be used? If so, I withdraw the suggested changes to the definition above...
    19. 4.2.9 - (formatting) - bumps into the preceding table, which is confusing.
    20. 4.2.12 - length - are there only two "kinds" of item in the content - characters and bits? If so, this needs to be simplified. If not, it needs to tell me where to find what a "kind" is and get the unit length. Until I read that images had a binary length, I was assuming that the length would either be "1" (for 1 picture) or the number of frames.
    21. nonNull ED SHALL always have some valid content, and length is greater than 0. - "valid" is an interesting statement, but the question remains - does data have to be non-null, even when reference isn't?
    22. Not that I want to really see it, but why no DTDL for SubPart? and equal?
  • 4.3 Character String (ST) specializes ED
    1. ST is primarily intended for machine processing? Where do we put text intended to be read by people???
    2. What does "the appearance of text does not bear meaning" mean? Is appearence the keyword or are we genuinely asserting that you can only use ST for meaningless text? Is "formalized text" (whatever that is) or "all kinds of names" meaningless text?
    3. "It SHALL be contained in-line - the ED.reference property cannot be used." - these SHALLs and SHALL NOT's seem extraneous in most cases. Wouldn't it be sufficient to say that ST SHALL comply with all invariants and be done with it?
  • 4.4 Character String with Code (SC) specializes ST
    1. "The original text of the code, if provided, is the content of the string." - these sort of statements (especially the footnote) are a bit confusing. As this is an abstract specification, it seems like its primary job is to indicate what various predicates and properties do, not what does or does not get sent over the wire. Thus, if provided makes no sense. Does code.originalText return a value or does it not? Why, if the string is required, would you want to make originalText optional?
  • 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>