2 Copyright © 2015 Open Geospatial Consortium
1.3 Future work
The following items were identified for consideration in future initiatives:
Detailed testing - The Schematron derivation tool was implemented in less than
four months. Only a very short amount of time was left to test the resulting Schematron. Future work should therefore include detailed testing. This is even
more important when considering the complexity of the AIXM schemas, both the conceptual schema also taking into account the Temporality Model and the
XML implementation schema.
Complete AIXM schema merging – Testbed 11 defined a process to merge the
information from AIXM extension schemas and the core schema on-the-fly. This is critical for parsing SBVR constraints that use concepts from AIXM extension
schemas for further details, see 8.2.3. The merging process defined in Testbed 11 supports features required for the
Testbed 11 demonstration. The process must be extended in order to support all aspects relevant for merging AIXM schemas.
Add support for choicesunions and association classes – Due to time and
resource constraints the automation tool only implements core schema constructs. AIXM choice and union types as well as association classes are not
supported yet. Future work should implement additional functionality – also taking into account the considerations on the handling of choice types as
documented in 8.1.2.
Continue the work on the geospatial vocabulary – Work in Testbed 11 focused
on the definition of a geospatial vocabulary that includes a profile of core geospatial terms and concepts. Future work should test the use of the vocabulary
in actual business rules, and implement support for spatial operators and geometry operands.
Regular expressions in SBVR rules – Some of the AIXM business rules define
constraints on the content of properties with textual value type e.g. that the text value shall have at most three digits. Such free-text descriptions of how a textual
value should be structured are very hard if not impossible for an automation tool to parse.
A solution would be to add a predicate to the SBVR grammar that supports the specification of a regular expression. The regular expression could be translated to
Schematron, which if XPath 2.0 is used may not even require an additional function library for the validation. For further details, see 8.1.5.
Schema-aware Schematron processor – The Schematron rules generated by the
automation tool could be simplified if they were written for a schema-aware Schematron processor. Especially the check to determine that a given object is of
a specific type could be improved this way using the schema-element XPath 2.0 function.
Support for rules involving elements of external schemas – At the moment the
automation tool cannot generate Schematron code for constraints if they address concepts from external schemas where the XML encoding is unknown.
The encoding could be unknown because the external schema has a specific
