Uploaded image for project: 'Technical Advisory Board'
  1. Technical Advisory Board
  2. TAB-1219

Data Dictionary - Normative Content?

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 2.0 CSPRD01
    • Fix Version/s: None
    • Component/s: Public reviews
    • Labels:
      None
    • Environment:

      Normative

    • Proposal:
      Hide

      By the numbers:

      1. The data dictionary in readable form should not be separate from the standard.

      2. The data dictionary, like other parts of the standard, should follow RFC2119 for requirement language.

      3. The data dictionary MUST mark its parts as normative/non-normative like any other part of the standard.

      4. I assume that "instance" is like an example and hence non-normative?

      BTW, be aware that you have already said that the schema controls over the documentation so it might be best to make this generated documentation non-normative in its entirety.

      Defining the semantics of these elements without resorting to this auto-generated diagram could be a good deal clearer.

      Show
      By the numbers: 1. The data dictionary in readable form should not be separate from the standard. 2. The data dictionary, like other parts of the standard, should follow RFC2119 for requirement language. 3. The data dictionary MUST mark its parts as normative/non-normative like any other part of the standard. 4. I assume that "instance" is like an example and hence non-normative? BTW, be aware that you have already said that the schema controls over the documentation so it might be best to make this generated documentation non-normative in its entirety. Defining the semantics of these elements without resorting to this auto-generated diagram could be a good deal clearer.

      Description

      4 Data Dictionary is only a reference to a generated PDF file in Appendix A. The document in Appendix A is very difficult to read and the annotations don't follow the usage of RFC 2119, as declared in 1.1 Terminology.

      For example (this isn't exhaustive):

      Outdated reference: Element Have - "Language code that is used throughout this document. Code MUST comply with RFC3066."

      Element Have / reportingPeriod - "...the duration may change..." Is that "may" normative?

      Element FacilityType / geolocation

      ***
      The single geometry that represents the Facility location. A WGS84 SRS element is mandatory and alternate SRS geometry elements can be provided. All geometry elements should be reflecting the same physical location.
      ***

      Does "mandatory" = "must" under RFC2119? Why depart from RFC2119?

      Element GeoLocationType / wg84Location - more "mandatory" language and lowercase "can."

      Element ServiceType / bedCapacity

      ***
      An indication of the bed capacity that the facility makes available for the community to know. It reflects fully staffed and equipped beds. The intention here is to provide an external view of where beds may be available in a health network. The intent is not for HAVE to become a hospital administration tool.
      ***

      Non-normative? Yes?

      I stopped here. There are another fourty (40) pages of such issues.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              patrick Patrick Durusau
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: