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.

Child Configuration

Many configuration options in Grooper are shared across the main container types: Data Model, Data Section, and Data Table. These properties allow you to control the behavior, appearance, and logic of all child elements within these containers. Understanding these shared properties helps you build more flexible and maintainable document schemas.

Appearance Properties: CSS styling

The "Style Sheet" and "CSS Class" properties allow you to define custom CSS rules that control the appearance and layout of the container and all its descendants in the Grooper Data Viewer (used during a Review for users to review Extract results).

• Style Sheet: Defines CSS rules that are applied to the the container and its child Data Elements.
• CSS Class: Applies a class name defined in a Style Sheet on a parent Data Element or in an Included Style Sheet set on the Data Model.
  • The Data Model's "Included Style Sheets" property allows users to reference a CSS file added to the Project as a Resource File. This allows multiple Data Models across multiple Content Models to utilize the same CSS styling.

Styles are written using standard CSS syntax.

• You can target elements by type (e.g., .DataField, .DataSection), by name (e.g., .Invoice_Number), or by using the self selector for the container itself.
• CSS defined at the container level cascades to all child Data Elements, enabling consistent styling across complex hierarchies.
• You can combine the "Style Sheet" property with the "Included Style Sheets" property on the Data Model for a combination of global and local styling.
• See the CSS Data Viewer Styling article for a complete writeup, including some information on CSS basics.

Behavior Properties

Fill Methods

The "Fill Methods" property lets you define a list of automated actions that populate or modify child fields during extraction.

• Primarily, "Fill Methods" are used to run "AI Extract" in Grooper.
• Fill Methods are executed for each instance of the container.
  • For Data Models, the entire document instance.
  • For single instance Data Sections, the scope of the single extracted section instance (or its "Miss Disposition" instance).
  • For multi instance Data Sections, each record in a repeating Data Section.
  • For Data Tables, each row.
• You can add multiple Fill Methods, and they will run in the order listed.

Lookups

The "Lookups" property allows you to configure external data lookups for child fields. This allows you to use one or more "Lookup Specifications" to integrate external data sources (such as SQL databases) into your extraction.

• Lookups can validate field values, auto-populate additional fields, or provide reference data from databases, XML files, or web services.
• Each Lookup Specification defines the criteria fields, target fields, data source, and trigger conditions.
• Lookups can be set to run automatically after extraction, when a field changes, or on demand.

Examples:

• Validate a "Vendor ID" against a master vendor list.
• Configure a lookup that uses the extracted "Policy Number" field to query an external insurance database. When a match is found, the lookup automatically fills in related fields such as "Provider Name", "Provider Address", and "Contact Number" in the Data Model, reducing manual entry and ensuring data accuracy.
• Cross-check extracted values with an external system for accuracy.

Variables

The "Variables" property enables you to define named variables that can be referenced throughout the container and its descendants.

• Variables can hold static values, results of expressions, or values calculated during extraction.
• They are accessible to all child fields (via their expression properties: Calculated Value, Is Valid, etc.), Fill Methods, Lookups, and validation rules within the container.
• Variables are useful for encapsulating reusable logic, storing intermediate results, or driving dynamic behaviors.
• Variables make it easy to share data or configuration values across the various properties that can access them.

Examples:

• Store a calculated "IsHighValue" flag to trigger special validation or formatting.
• Define a variable for a tax rate used in multiple calculations.
• Define a variable "IsInternational" that evaluates to true if the "Country" field is not "USA". Use this to trigger specialized validation or lookup operations.

Validate Rule

The "Validate Rule" property lets you attach a custom Data Rule to the container, providing advanced validation logic that applies to the container and all its children.

• The rule is executed during validation events. Validation events execute:
  • After extraction.
  • When a user edits data.
• Use Validate Rules to enforce business logic that spans multiple fields, such as cross-field dependencies or aggregate checks.
• If the rule fails, a validation error is displayed, and the user is prompted to correct the data.

Examples:

• Ensure that the "Total" field matches the sum of line items.
• Require that at least one contact method (phone or email) is provided.
• Enforce that a "Date of Birth" is before a "Service Date".

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)