Content

In addition to this introduction, the document includes:

• An example based on the definition of an XML schema for Mondrian, following the Mondrian Documentation.

• A breakdown of each schema element, detailing the corresponding tables, their relationships, and the XML templates used for data transformation.

• The process of transforming elements to generate the schema.

Root of the schema template: schema_template.xml

Below is the root of the schema template.

<Schema>
    {Cube}
</Schema>

The root can contain only one token (in this case, the {Cube} token). If multiple tokens or none are found, an error is raised.

• Tokens are defined using a name enclosed in { and }.

• Token names are case-insensitive.

• Tokens reference either sheets in the spreadsheet or columns in the sheet associated with each element.

In the example, a schema consists of one or more cubes.

Starting from the root, each element must have an associated sheet and a template file, where the sheet’s columns or other components are included.

Cube

Only one cube is defined in the schema; therefore, the table contains only one row.

• If we need to reference this element from another, we add a primary key column. The name of this column must consist of the sheet name followed by the _pk suffix.

• To reference elements from another table, we add a foreign key column, named after the referenced sheet with the _fk suffix.

In this case, a cube has an associated table. However, since other elements can also have associated tables, we add the foreign key to the cube (as well as to each element with an associated table).

Regarding the template, we can include two types of tokens:

• Tokens referencing table columns: these will be replaced with a value.
  
• Tokens referencing other elements (referenced by the sheet name): these will be replaced with another template.

    <Cube name="{name}">
        {Table}
        {Dimension}
        {Measure}
        {CalculatedMember}
    </Cube>

When including tokens that reference other sheets, each token must be placed on a separate line, as they will be replaced with templates.

Table

Since the tables are referenced by other elements, we define a primary key with values to allow referencing (as we did from the cube).

The template only needs to include the table name using the specified syntax.

                <Table name="{name}" />

Dimension

Each dimension is included in a cube and can also contain other elements that reference it.

In the template, the sheet’s columns and the containing element (which includes one or more hierarchies) are referenced.

        <Dimension name="{name}" foreignKey="{foreignKey}">
            {Hierarchy}
        </Dimension>

Hierarchy

Hierarchies reference both the dimensions that contain them and their associated tables.

In the template, we can see that it includes the table and the levels that make up the hierarchy.

            <Hierarchy name="{name}" hasAll="{hasAll}" {allMemberName} primaryKey="{primaryKey}">
                {Table}
                {Level}
            </Hierarchy>

Level

Levels do not need to be referenced, so they do not include a primary key. Instead, they reference the hierarchies they belong to.

The template references the columns of the associated sheet.

                <Level name="{name}" column="{column}" type="{type}" uniqueMembers="{uniqueMembers}" />

Measure

Measures are included in cubes and must reference them. Since they do not need to be referenced, they do not require a primary key.

The template includes the columns from the sheet.

        <Measure name="{name}" column="{column}" aggregator="{aggregator}" formatString="{formatString}" />

CalculatedMember

Calculated members may have components that must be referenceable (they have a primary key) and are included in cubes.

The template shows the elements they contain.

        <CalculatedMember name="{name}" dimension="{dimension}" formula="{formula}">
            {CalculatedMemberProperty}
        </CalculatedMember>

CalculatedMemberProperty

Finally, we have the properties of the calculated members they reference.

The template uses the columns from the corresponding sheet.

            <CalculatedMemberProperty name="{name}" value="{value}" />
            

Conclusions

The tab2xml package offers an efficient and scalable method for generating XML files from tabular data. By using structured templates and relational tables, the package facilitates the management of complex datasets while maintaining consistency and accuracy.

This approach is particularly advantageous for scenarios requiring the generation of large XML files or handling multiple entities with defined relationships. It streamlines the transformation process, reduces manual errors, and enhances maintainability by allowing users to modify the underlying data without altering the XML structure.

The provided example, based on the Mondrian schema, demonstrates how to apply this methodology to real-world use cases. This framework can be extended to other domains requiring XML generation from relational data, offering a flexible and robust solution for data-driven XML creation.