Uploaded image for project: 'OASIS Emergency Management TC'
  1. OASIS Emergency Management TC
  2. EMERGENCY-48

Data Dictionary - Normative Content?

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: EDXL-HAVE-v2.0
    • 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. "
    • Resolution:
      Hide

      The addition of a conventional data dictionary resolves this issue.

      Show
      The addition of a conventional data dictionary resolves this issue.

      Description

      TAB-1219

      "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.
      "

      Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 2.0 CSPRD01

        Attachments

          Activity

            People

            • Assignee:
              rexbrooks Rex Brooks
              Reporter:
              darrell.odonnell Darrell O'Donnell (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: