Revision history OWS-8 Report on Digital NOTAM Event Specification

Copyright © 2011 Open Geospatial Consortium. 3

1.4 Future work

Improvements in this document are desirable to the following topics. ● Validation of Text NOTAM Production Rules - Validation of the information contained in textual NOTAMs via schematron rules is complex. Given the scope of the overall validation task at hand as well as the resources for OWS-8, the Text NOTAM production rules were not included in the validation efforts except for some production rules from general sections. This task was deferred to future activities. ● Validation of Digital NOTAM - This document has identified a majority of the normative statements discovered from the DNES document, though not all scenarios are covered in completion. During development of the schematron rules, these normative statements were used as a guide - considering each statement and whether it’s appropriate for a schematron rule to enforce. Not all normative statements have been considered and these have been marked with TBD. ● Invocation of validation tools - When considering the most appropriate way to invocate the validation tools for AIXM and Digital NOTAM in the context of OGC SDI recommendations resulted with the idea of wrapping the validation tool into a WPS process. This idea expanded to a WPS Application Profile that describes a set of processes for validating conformance of GML documents against a GML Application Schema. Considerations include: ○ A multiple process approach where the process name identifies the validation profile to use; e.g. validateAIXM, validateDNOTAM, valdiateCityGML. The WPS mechanisms then provide appropriate capabilities advertisement via the list of processes and using describeProcess. ○ Alternatively a single process approach that includes a parameter to identify the application schema or validation profile to apply during validation. More easily expandable and more likely supported in the existing approach to defining WPS Application Profiles where each process must be defined, but may also require a getSupportedValidationProfiles process, which seems to introduce unnecessary duplication of interface abstraction. ○ Potential process parameters: ■ URL of content to validate, examples include a GML document or WFS response. ■ An identifier to nominate the application schema to use for validation, as already discussed. Perhaps call this the Validation Profile. The WPS process will need to support the application schema, and decide what validation technology or technologies it will apply; XML Schema, Schematron, RelaxNG, custom validation to handle otherwise non-testable constraints. ■ Output format for validation results, if more than one is to be supported. 4 Copyright © 2011 Open Geospatial Consortium. ○ Define the response format of the validation result. ○ Include a schema only validation process. The server would not need prior knowledge of the schema as long as the schemas to apply can be derived from the XML file. ○ Include a schematron only validation process where the schematron file is provided by the caller. Could also provide RelaxNG, XML Schema and possibly other validation methods this way. ● Enrichment of DNOTAM data – In some cases the normative statements of the Digital NOTAM Event Specification presume the availability of information which is not part of a DNOTAM e.g. checking against designators in BASELINE data. To process such rules a validation tool must provide a method for retrieving such information from an AIXM data store. This is closely related to the Event enrichment in the Event Architecture of OWS see OGC 11-093, section 9.5.1. Some of the observed issues presumably also apply for enrichment regarding automatic validation. Hence, a general approach for dealing with dynamic features in web service architectures should be discussed.

1.5 Foreword

This document is a deliverable of the OGC Web Services OWS Initiative - Phase 8 OWS-8. It describes the results of the conceptual and schematron rule based validation of the Digital NOTAM Event Specification DNES. Various conceptual aspects were identified which need clarification andor revision. Schematron rules were developed for a number of the DNES scenarios. This document contains coverage tables which document normative statements from the DNES and indicate which of them can be tested with existing schematron rules. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.