Available Options Solutions Conclusion and Recommendation Available Options Solutions

18 Copyright © 2011 Open Geospatial Consortium.

5.4.4.3 Conclusion and Recommendation

Regarding clarification of section 2.1: the first option requires a change to the AIXM-TM. That change may impact existing systems and appears to be unnecessarily restrictive. The second option is therefore recommended. Regarding creation, provision and encoding of dnotam:Events: the DNES should require that data originators create and maintain dnotam:Events with Permdeltas and according Baselines keeping them in synch following the Temporality Model. It should require that the default behavior for publishing Events is to encode them using both timeslice types. However, it should also explicitly mention that applications may define ways to let clients indicate which timeslice type they want to receive. Relevant statements in the DNES should be reviewed and revised if necessary with respect to inconsistent usage of static AIXM feature data timeslices: Permdeltas and Baselines. 5.4.5 Scenario Identifier for Event Update 5.4.5.1 Problem Statement and Description Section 5.6 defines the rules for encoding an update to a previously published dnotam:Event. Such updates are currently defined for the cases of updating an Event’s end time and for cancelling it. In both cases, the update is encoded as another dnotam:Event with a Permdelta timeslice instead of a Baseline. It is essential that each dnotam:Event gets a unique gml:identifier. If a dnotam:Event did not have such an identifier then it cannot be updated as defined by the DNES. That the originatorpublisher of a dnotam:Event has to assign a unique gml:identifier to the Event is implicit as an Event is an AIXM feature and AIXM features require that they get a unique gml:identifier value - see the “Feature Identification and Reference” document for further details. As this requirement on Event originatorspublishers is not explicitly recorded in the DNES, there is a chance that developers and users of the DNES may not comply with it.

5.4.5.2 Available Options Solutions

As the requirement to assign a gml:identifier is implicit the DNES does not necessarily need to be changed. On the other hand, clarification on gml:identifier assignment may avoid confusion in the future. The last paragraph in DNES section 3.2 elaborates that an “Event is a regular AIXM feature” and that it can be updated because it has timeslices following the Temporality Model. A simple addition of “which includes the assignment of a unique gml:identifier to the Event” to the statement “each Event will be first encoded as a Copyright © 2011 Open Geospatial Consortium. 19 PERMDELTABASELINE TimeSlice pair” would suffice to clarify that each dnotam:Event has to have a unique gml:identifier.

5.4.5.3 Conclusion and Recommendation

Even though repetition of requirements that are inherited from other specifications usually is a bad idea, we recommend to make an exception here and to revise the text in DNES section 3.2 as described in the previous section. 5.4.6 Embedding the Standard Version into the Scenario Identifier 5.4.6.1 Problem Statement and Description Section 3.4 specifies how the scenario that a dnotam:Event was instantiated for is identified. The “scenario” property of a dnotam:Event contains the respective identifier. The DNES version number is embedded into this identifier. It is good to know the version of the scenario that a given Event was encoded with because the rules data encoding, automatic validation and text NOTAM production may change between different versions of the DNES. Code - for example schematron validation rules - that was written for a specific scenario and version may thus be more easily re-used if the scenario rules have not changed. That the “scenario” property also includes the DNES version is problematic, though, because it overloads the meaning of that property.

5.4.6.2 Available Options Solutions

It may be that there are other benefits to this approach that have not been identified here. If this is the case then the DNES should identify them. Otherwise, scenario identifier and DNES version should be separated and stored in distinct Event properties. Not mixing independent concepts in the same property value is good modeling practice.

5.4.6.3 Conclusion and Recommendation

We recommend to separate event scenario and DNES version and to model them as distinct dnotam:Event properties. 5.4.7 Improve Path Notation in Data Field Mappings 5.4.7.1 Problem Statement and Description The DNES presents the data that is usually provided by the data originators for each event category in the form of “templates”, using EBNF Extended Backus Naur Form and provided in graphical representation. Tables then provide a mapping from the data 20 Copyright © 2011 Open Geospatial Consortium. items contained in the templates to the relevant fields in the AIXM model. The mapping is made through path expressions like the following: ● Navaid.type ● NavaidEquipment and NavaidNavaidOperationalStatus.operationalStatus ● RunwayDirectionManoeuvringAreaAvailability.operationalStatus ● AirportHeliport..Availability..Usage.operation ● AirportHeliport..Availability..UsageConditionCombination.logicalOperator ● AirportHeliport..Availability..Usage..FlightCharacteristics ● AirportAirportTimeSliceTimePeriod.beginPosition ● EventEventTimeSlice.validTimetimePosition ● EventEventTimeSlice.featureLifetimebeginPosition ● aixm:Surfacegml:patchesgml:PolygonPatchgml:exteriorgml:Ringgml:curveM embergml:Curvegml:segments Apparently, the path notation used throughout the document is inconsistent: ● Sometimes timeslices are explicitly mentioned. ● Sometimes the path is abbreviated using “..”. ● Sometimes a more UML OCL like expression is used with dot notation - for example Navaid.type. ● Sometimes an XPath like expression is used. ● etc. A consistent path notation is desirable to avoid confusion and misunderstandings.

5.4.7.2 Available Options Solutions

Two options to improve the path notation in the AIXM mappings were identified. Option 1 The first option involves stating the class name of the relevant AIXM feature type first, followed by a dot-separated list of property names to point to the exact property that is of interest. For the examples from the previous section, this would look as follows: Current DNES Notation Proposed Notation option 1 Navaid.type Navaid.type so this is already ok NavaidEquipment and NavaidNavaidOperationalStatus.operationa lStatus Navaid|NavaidEquipment.availability.o perationalStatus