Data Field Container and Data Element Container

Data Field Container and Data Element Container are two base types in Grooper from which "container" Data Elements are derived. Container Data Elements (data_table Data Models, insert_page_break, Data Sections table Data Tables) serve an important function in organizing and defining behavior and extraction logic for the variables Data Fields and view_column Data Columns they contain.

• While "Data Field Container" and "Data Element Container" are distinct classes in the Grooper Object Model, they are closely related. While Grooper scripters/experts should know the difference, for most practical purposes, the terms are used interchangeably (or they're just called "containers" or "container elements"). See Object Model info for more.

About

Certain Data Elements act as "containers" for other Data Elements. These include:

• data_table Data Models
• insert_page_break Data Sections
• table Data Tables
  • Data Tables are a specialized container for tabular data. They can only contain Data Columns as their children.

These containers serve three primary purposes:

1. Organization: They organize child Data Elements in a Data Model.
2. Hierarchy: They create branching points in a Data Element hierarchy (with the Data Model at the root). This allows you to model documents with nested sections, repeating tables, and collections of fields.
3. Child Configuration: Container Data Elements share special properties that control how their child Data Elements are displayed and behave during Review, are extracted, certain validation controls, and how lookups are performed.

Organization

Data Models, Data Sections and Data Tables can't extract data without child elements:

• variables Data Fields can be added to Data Models and Data Sections
• view_column Data Columns can be added to Data Tables.

This is why Data Models, Data Sections and Data Tables are called "containers". If nothing else, they are buckets that hold Data Fields and, in the case of Data Tables, Data Columns.

In terms of organization, Data Sections play an important role. For larger Data Models, it's often useful to group similar Data Fields together. To do this, Data Fields (and other Data Elements) are simply added to a Data Section with no section logic defined.

Grouping Data Elements with a Data Section can:

• Help Grooper designers locate fields in a large Data Model.
• Help Review users using the Data Viewer locate fields when reviewing extraction results.
• Provide useful ways to target Data Elements for CSS styling.

Example:

In this example, the "Header Details" and "Amounts" sections are used to organize Data Fields related to invoice processing.

data_table Data Model

insert_page_break Header Details

variables Vendor

variables Invoice Number

variables Invoice Date

variables Due Date

insert_page_break Amounts

variables Subtotal

variables Tax

variables Discounts

variables Amount Due

• When adding a Data Section only used to organize child Data Elements. Be sure to configure the following properties:
  • Leave "Extract Method" blank.
  • Set "Scope" to Single Instance.
  • Set "Miss Disposition" to Default to Parent.
    • Because this kind of Data Section doesn't have an extract method defined, its child extractors will fail if you don't set the Miss Disposition properly. Without an extract method defined, the Data Section effectively always "misses". Setting to "Default to Parent" ensures its child Data Elements have a document instance to extract from.

Hierarchy

A Data Model in Grooper defines the complete structure of data to be extracted from a document. Its hierarchy is essential for accurately subdividing documents, capturing complex relationships, and extracting collections of related data.

• Data Sections and Data Tables play an important role in defining that hierarchy, creating branches in the Data Model hierarchy.
• Data Fields form the terminal "leaves" of each branch in Data Models and Data Sections.
• Data Columns form the terminal "leaves" of each Data Table.

Understanding a Data Model's schema hierarchy

A "schema" is the formal structure that outlines the organization, relationships, and definitions of data within a system. The Data Model is the root of your schema. Its hierarchy is built using several key element types (called "Data Elements"). This hierarchy defines how Data Elements are related and ultimately how data is collected.

• Data Section: The primary tool for subdividing a document into logical parts.
  • Data Sections can be nested to create multi-level hierarchies, representing real-world document structure.
  • Each Data Section can extract a single instance or a collection of repeating records, depending on its "Scope" property.
  • Example: A single "Amounts" section at the bottom of an invoice.
  • Example: Multiple "Claim" sections on an EOB (explanation of benefits) form.
  • Example: Multiple "Semester" sections on a college transcript.
• Data Field: The primary tool for extracting individual values.
  • Data Fields are the leaf elements in the Data Model's tree.
  • Example: An "Invoice Number" field on an invoice.
  • Example: A "Data of Birth" field on an enrollment form.
• Data Table: A specialized tool for capturing tabular, repeating data.
  • Data Tables collect the rows, columns and cells in a table on a document.
  • Data Tables can only contain Data Columns.
  • Example: A "Line Items" table to collect line item rows on an invoice.
  • Example: A "Course Performance" table on a college transcript detailing performance results for each course a student enrolled in during a semester.
• Data Column: A specialized tool to capture cell values in a table.
  • Data Tables and Data Columns work together to define the structure (rows/columns/cells) and extraction logic required to collect tabular data.
  • Data Columns are the leaf elements of a Data Table.
  • Example: A "Unit Price" column on a line items table.
  • Example: A "Grade Points" column on a course performance table.

Data Sections role in creating hierarchy

Data Sections are not just for grouping fields—they define the logical and extraction boundaries within a document. By adding and nesting Data Sections, you can:

• Subdivide a document into meaningful parts (e.g., "Header", "Body", "Footer").
• Represent collections of repeating records (e.g., multiple "Claim" or "Semester" sections).
• Establish parent-child relationships, where each section can contain its own fields, tables, and further nested sections.
• Control extraction scope, validation, and display for each part of the document.

For example, a Data Section with "MultiInstance" scope will extract a collection of records, each with its own set of fields and possibly nested sections or tables.

Example: Hierarchical Data Model

This Data Model represents a portion of information collected from EOB (explanation of benefits) forms. EOB forms will often have several claims per patient, with a table detailing information about each procedure for each claim. Grooper's hierarchical data modeling can capture this data structure with a Data Model schema like the one below.

data_table Data Model

insert_page_break Data Section (SingleInstance): "Patient Info"

variables Data Field: "Patient Name"

variables Data Field: "Date of Birth"

insert_page_break Data Section (MultiInstance): "Claims"

variables Data Field: "Claim Number"

variables Data Field: "Service Date"

table Data Table: "Procedures"

view_column Data Column: "Code"

view_column Data Column: "Description"

view_column Data Column: "Amount"

insert_page_break Data Section (SingleInstance): "Provider Info"

variables Data Field: "Provider Name"

variables Data Field: "NPI"

insert_page_break Data Section (SingleInstance): "Totals"

variables Data Field: "Total Charges"

variables Data Field: "Amount Paid"

In this example:

• The "Claims" Data Section extracts a collection of claim records, each with its own fields, tables, and nested "Provider Info" section.
• "Procedures" is a Data Table within each claim, capturing repeating line items.
• "Patient Info" and "Totals" are single-instance sections, representing unique parts of the document.

Object Model info

Important Note:

• Data Model, Data Section, and Data Table all inherit from "Data Field Container"
  • "Data Element Container" inherits from Data Field Container
  • Only Data Model and Data Section inherits from Data Element Container.
• Data Table inherits from "Data Field Container" not Data Element Container.

Data Field Container

Type name: Grooper.Core.DataFieldContainer

Inheritance

Grooper Object (Grooper.GrooperObject)

Connected Object (Grooper.ConnectedObject)

Node (Grooper.GrooperNode)

Data Element (Grooper.Core.DataElement)

Data Field Container (Grooper.Core.DataFieldContainer)

Derived Types

Data Field Container (Grooper.Core.DataFieldContainer)

Data Element Container (Grooper.Core.DataElementContainer)

Data Model (Grooper.Core.DataModel)

Data Section (Grooper.Core.DataSection)

Data Table (Grooper.Core.DataTable)

Data Element Container

Type name: Grooper.Core.DataElementContainer

Inheritance

Grooper Object (Grooper.GrooperObject)

Connected Object (Grooper.ConnectedObject)

Node (Grooper.GrooperNode)

Data Element (Grooper.Core.DataElement)

Data Field Container (Grooper.Core.DataFieldContainer)

Data Element Container (Grooper.Core.DataElementContainer)

Derived Types

Data Element Container (Grooper.Core.DataElementContainer)

Data Model (Grooper.Core.DataModel)

Data Section (Grooper.Core.DataSection)