Conclusion and Recommendation Angle values

12 Copyright © 2011 Open Geospatial Consortium.

5.3 Specification and Usage of Conformance Targets

5.3.1 Problem Statement and Description

The DNES contains many normative statements. Many of them apply to an encoded dnotam:Event. However, some apply also to the data originator or publisher. Some of these statements can be tested with automated tools. It is not always clear for which entity a given statement is relevant. This makes it more difficult for a data originator or developer of a DNOTAM validator tool to identify the statements that are relevant for himher.

5.3.2 Available Options Solutions

Some specifications in the IT domain clearly identify so called conformance targets to which normative statements in the specifications are unambiguously assigned. For example, the WS-I Basic Profile 2.0 1 defines conformance targets such as “Message”, “Receiver” and “Sender”. The following extract from WS-I Basic Profile 2.0 section 2.1 explains the use of conformance targets in combination with requirements: “ Requirement levels, using RFC2119 language e.g., MUST, MAY, SHOULD indicate the nature of the requirement and its impact on conformance. Each requirement is individually identified e.g., R9999 for convenience. For example: R1012 An ENVELOPE MUST be serialized using either UTF-8 or UTF-16 character encoding. CORE TESTABLE BP1018 This requirement is identified by R1012, applies to the target ENVELOPE, and places a requirement upon envelopes. Each requirement statement contains exactly one requirement level keyword e.g., MUST and one conformance target keyword e.g., MESSAGE. The conformance target keyword appears in bold text e.g. MESSAGE. Other conformance targets appearing in non-bold text are being used strictly for their definition and NOT as a conformance target. Additional text may be included to illuminate a requirement or group of requirements e.g., rationale and examples; however, prose surrounding requirement statements must not be considered in determining conformance. ” As we can see, the requirements stated in WS-I Basic Profile clearly identify to which conformance target they apply. Rules are in place to ensure that requirements are unambiguous with respect to the target they apply to. 1see http:ws-i.orgProfilesBasicProfile-2.0-2010-11-09.html Copyright © 2011 Open Geospatial Consortium. 13 In addition, we can see that requirements have an identifier which facilitates referring to specific requirements. They also have tags. The tag “CORE” in the example above is used to indicate that this requirement always applies for an ENVELOPE. Another value used by the WS-I Basic Profile is “HTTP-TRANSPORT”, indicating that a given requirement applies if HTTP is used for communication. Finally, the tag “TESTABLE” is used to indicate if automated tests exist with which the requirement can be checked the other value would be “NOT_TESTABLE” - this is comparable to the “rule coverage” in the tables of section 8 in this report. If a requirement is testable, then the last tag identifies the tests and also provides a link to the test. The OGC recently also established a policy that requires new standards to also clearly identify conformance targets and the requirements that apply for them. The DNES should adopt a similar approach, i.e. clearly list and describe the set of relevant conformance targets - for example “Event” and “Data Originator”, maybe also “Text NOTAM” - and ensure that each normative statement clearly identifies the conformance target that it applies to.

5.3.3 Conclusion and Recommendation

We recommend revising the DNES as described in the previous section. While the normative statements requirements do not necessarily need to be identified as shown in the WS-I Basic Profile, they should at least explicitly name the relevant conformance target.

5.4 Request for Clarification

5.4.1 Container Format for Events 5.4.1.1 Problem Statement and Description The DNES does not require a specific container format for encoding DNOTAM Event data. In many examples, however, AIXMBasicMessage is used to encode the data. Developers and users may thus be tempted to think that AIXMBasicMessage is the required container format. During a telcon the sponsors explained that even though AIXMBasicMessage is often used in examples other container formats are perfectly fine for transporting the relevant data. These container formats could for example carry application specific data, in addition to the DNOTAM Event data. The lack of documentation regarding the container format for communicating a DNOTAM Event can cause confusion and can lead to developments that are based on false assumptions.