Converter
Overview.
Using the converter.
Converter screenshots.
New converter version.
Implementation details.
Schedule.
Known issues.
Implementation details
This paragraph can only bring a short summary.
If you are interested in more details, then please call or mail us, or simply use the contact form. Many thanks.
The converter uses a metadocument and a metaformat, which are both central for the conversion.
For the conversion, the source document is first transformed into the metadocument, using Java, and is then from the metadocument mapped into the target format, via XSLT (and Java).
The schema of the metaformat includes all schema types of the implemented formats. These types are structured under the element "metaDocument". This metadocument contains all information from the source format, and it is always saved.
We have developed an own schema for the metadocument. A schema-based metadocument allows
- the converter to validate metadocuments
- access of metadocuments via Java Architecture for XML Binding (http://java.sun.com/webservices/jaxb/), as well as generation of metadocuments from Java objects. This provides a very smooth interface to a dataset editor and to the database.
- exchange of ELCD datasets without ELCD database (all information required by one ELCD dataset is contained in the metadocument, information which is, in the ELCD database, stored in literally hundreds of XML files!).
It will in future be possible to generate source formats, for all supported formats, from the metadocument alone without access to the original source data sets.
The metaformat can be seen as a compilation of the different implemented formats.
For every process data set, ELCD, EcoSpold and ISO@Spine format "branches" are provided. An additional "any type" element (with namespace "#other") is foreseen for additional data formats.
At present, data formats treat only process data sets. However, an extension is provided here, as well, in order to be able to include also other elements in the metadocument and -format which might be proposed in future.
Evidently, two mappings need to be provided and applied. First, a mapping is required from source format data set to the metadocument, and second, a mapping is needed from the metaformat to the target format.
The format of the source data sets is automatically recognised and validated afterwards, and the metadocument is foreseen to be validated against the metaformat schema as well.
The picture below shows the schema of the metaformat in a bit more detail.



