Document contributor contact points

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.