Introduction
In 2006 the Dutch Kadaster Topographical Service held a fourth and final GML relay to demonstrate the use of the TOP 10 GML schema (also known as TOP10NL) with a number of commercial products. Safe Software participated behind the scenes with several vendors to set up a number of data model transformations from the TOP10NL model into and out of their systems. Safe also has created Workbench workspaces for bringing this data into and out of other commercial products, and these are all available off this page.
One of the significant challenges centered around the use of multiple geometries per object in the TOP10GML model. The vendor systems discussed here did not support this. So the FME had to perform a data model transformation to normalize the data model from multiple geometries per object to a single geometry per object accompanied by an additional attribute table. Within the Bentley, ESRI, MapInfo and Oracle systems (the list perhaps can be extended, but we tested only these four), built in functionality to then join the geometry tables back to the shared attribute table presented the user with a single consistent view of the data.
Lastly, when exporting back to GML from the vendor data model, the FME performed the join of the attributes back to the geometries, and reassembled the multiple geometries into a single object for export, thus restoring the original data model.
Note that these configurations require FME 2006 GB build 2573 or later to run.
FME 2011 added support for multiple geometries per object to Oracle and SQL Server
NOTE
The latest TOP10NL schema definition (the XML Schema Definition file) differs from the old schema in ways that can be surprising. If you find that you have some data which suddenly starts to produce features with no geometry, the problem is that the data is using the old schema. Since the schema documents are not versioned, we have no choice but to read on the basis of the newest schema. You can contact us for a copy of the old schema, which will restore the old behaviour. However, you should look into migrating your data into the most recent definition of the schema.
Configurations
For configurations see the related format page, such as:
Data Normalisations
Dutch Top10 GML supports multiple geometries per feature, and this is not what we can see quite often in other systems. Our Top10 GML reader while reading TOP10 features brings them to a traditional form with only one geometry per feature, and this is what can be written to any other system. But here is the problem - every TOP10 feature can be translated to more than one feature with its unique geometry, but every set of attributes will be copied with each new separate geometry. As result, we may end up with a situation, when we will have to edit one attribute value in several places (and if we won't do so, we may lose our changes made only to one feature).
Normalization helps to avoid this situation. Geometries are kept separately from attributes, and joined by a key attribute, gml_id in case of TOP10. For example, we may have a road edge feature, a centerline, and a road surface polygon sharing the same gml_id and the same set of attributes. All the attributes will go to a separate table. Changing Status attribute value while editing centerline will be immediately reflected on road edges and road polygon - just because it is the same attribute for all features.

The workflow in Workbench can look a bit different for every system, but generally it makes use of two main things - one set of features is passed through DuplicateRemover, where we delete all duplicate records, which we got after reading TOP10, and then through the GeometryRemover to ensure that the geometries are being deleted. What is left goes to an attribute table. The second set of features goes through an AttributeRemover, and only geometries and key attributes survive and go to the writer.
Some systems may require template projects or databases (GeoGraphics, ArcGIS), other - post-processing queries (CREATE VIEW statements for Oracle) or predefined workspaces (MapInfo). The process can be easily (or not so) accommodated to other systems where joining tables is possible in some way.
Reconstructing TOP10 format can be done with FeatureMerger where geometries are combined with the attributes by gml_id, and the writer takes care of everything else.