---
url: >-
  /statelake/administering-statelake/designer/data-definitions/file-definitions/xml-file-definitions/design-xml-file-definitions/xml-dataview-records-tab-xml-file-definitions.md
---

# XML Dataview - Records Tab - XML File Definitions

**XML Dataview** will prompt for information about the file as specified on the initial screen, starting with the **Records** tab.

::: info
**Statelake** forces all record names and field names to uppercase for consistency across all definitions.
:::

The **Records** tab window is split into 2 distinct panes - **Available Records** and **Selected Record**.

::: info
Some records or elements will be automatically populated when the tab is opened. These are read from the **Schema** file that you identified on the initial window. And since you cannot get to the design canvas without specifying a **Schema**, then there will always be some pre-population.
:::

In this example, the specified **Schema** file has been read, and an entry has been made under Available Records.

## Fields

| Field Name | Description |
|---|---|
| Selected Record  *Name* | The **Name** of the record that has been selected. This will be loaded from the **Schema**, and will become the name of the dataview. Double-click on the item from **Available Records** to populate this field, and also populate **Root Node**. |
| *Root Node* | Name of the **Root Node** for the dataview.**Root Node** in this context is the parent element or file identifier for the group of fields and records that you are adding to this dataview. You will see that the path to the fields will be constructed based on the **Root Node** you specified.Each separate dataview must have its own top-level **Root Node**.See the warning below.::: infoIn a tree structure, the **Root** **Node** is either the topmost or the very bottom branch, depending on how the tree is represented visually. It is the master or starting point – the point from which everything else stems and represents the ultimate objective or main choice.Then there are the **Branches**, which stem from the root, and represent different options. And the “**twig**” or **Leaf** node, which are the last options attached at the end of the **Branches**. In **Statelake**, these are referred to as an “expanded” Root Node.All nodes, irrespective of whatever type, only apply to the dataview it is in.:::::: warningBefore saving the dataview check that the top-level **Root Node** is still correct. If you accidently attempt to select a field while still on the **Records** tab, you will overwrite the value of the **Root Node** - and this will break the **File Definition**.::: |
| *Namespace* | The **Namespace**.A **namespace** is a logical declared container space which groups together and stores the names associated with one particular event or process. |
| *Abstract Type* |   |
| *Create separate file for each record* | Click to create a separate file for each record. |
| *Create fields as additional nodes* | Click to create fields as nodes. |

## Buttons

| Button Name | Description |
|---|---|
| OK | Click to save any changes you have made. All changes will be lost if you do not click the **OK** button. |
| Cancel | Click to **Cancel** any changes you have made. |

## Records

If there are multiple entries under **Available Records**, scroll down until the one you want as your **Root Node** is highlighted and double-click on it to select.

Once an item from **Available Records**  has been selected, and the fields **Name** and **Root Node** have been completed, any **Branches** will appear under **Available Records**.

These **Available Records** (such as **POheader**) can be displayed in **RED** text - this means that these entries are compulsory, not optional i.e. there must be at least one header record.

In our example, the **Root Node** is called M10B2BORDER. This is the wrapper name for the entire dataview query. On the occasion that there are fields under this wrapper **Root Node** itself, they could record information such as who sent the file, when it was sent, and the receiver identity – information that only refers to the file as a whole and is not required more than once. Such fields would be ignored.

::: info
Why is this top **Root Node** is set to the wrapper name rather than the 1st set of records **POheader**?

Because in **Statelake**, a **Root Node** must be set if you expect to have multiple header records - else there can be only one ( **1** ).

For example, there will be multiple header records in POheader, so for **M10B2BORDER** to extract those multiple records, the **Root Node** must be set on **M10B2BORDER**.

So the top initial **Root Node** would always be set to the wrapper.

In this example, **POheader** is not set as a node and will be referred to as a **Branch**.
:::

:question_mark:

*Notice the \<E> for element beside each entry*

::: info
There are two (2) symbols to the immediate left of the field name. The first is a plus ( + ) or a minus ( - ) sign. Click on the plus ( + ) to expand any group entry, and click on the minus ( - ) to shrink it.

A BLUE \<E> signifies that the item is a non-repeating complex element (a record).

A folder icon identifies a repeating complex element (repeating record).

A **YELLOW T** indicates a simple element (a field),
:::

**M10B2BORDER**  and **POheader** are both elements, as shown in the **Schema** below. But the placement of **POheader** identifies it as a **Branch**.

*Start of the Schema showing the Root Node (M10B2BORDER) and first Branch (POHeader)*

::: info
The structure in the schema file **PurchaseOrderFull.xsd** determines how these field relationships are handled within this **XML File Definition**.

The top level in a dataview structure tree is referred to as the **Root Node** - the name given to the group of records. It is the start of the structure tree for that particular dataview. In this example, **M10B2BORDER** is the wrapper and dataview name given to this group of purchase orders. It is the top uppermost wrapper containing multiple header records.

The **POheader** is the group of header records branching off the **Root Node**. It is the parent for each **XML** detail record and in this example, identifies the next level of records and fields within each purchase order header (through the repeating element **POdetail**).
:::

To expand any group, click on the plus ( + ) symbol beside it - this will show the fields within this record grouping.

In this example, clicking the plus ( + ) symbol shows that the header for each record can have a selection of fields such as **StoreCode** and **SupplierCode**. Expand the window or drag the separator bar between the panes down if required to enlarge the **Available Records** pane.

The last field item in **POheader** is called **POdetail**, which is a dataset or group of records in its own right, with its own set of fields.

It is shown with a folder symbol, indicating a repeating complex element or repeating record - so each **POheader** record can contain multiple **POdetail** records.

::: info
The asterisk (\*) at the end of the field name means that you can have more than one of these fields in a single record. There is no limit. However, the use of an asterisk in this way is dependent on the design of the **Schema**. In particular, some **Schema** may indicate that everything repeats, so the structural shape will have to be determined by other means.

A **RED A** at the end of the field name identifies the field as an attribute.
:::

To expand the folder element **POdetail**, click on the ( + ) symbol beside it or double-click on the name.

Each detail record in **POdetail** that has its own series of fields, and each can have more than one of these fields in a single record. Scroll up and down to see them all if required.