Document Purpose: Explain GLOMIDCO's internal data structure for representing the Discoverable Taxonomy Set (DTS)
Source: GLOMIDCO development notes, December 2016, Section 4
Target Audience: XBRL processor developers, architects
Last Updated: January 2026
The Challenge:
XBRL taxonomies contain many different types of elements (concepts, labels, references, dimensions, hypercubes, etc.) with complex relationships between them. How to represent this efficiently in memory?
GLOMIDCO's Solution:
A unified Node structure that can represent ANY XBRL element, organized in multi-dimensional maps with connection objects representing relationships.
Key Insight:
Traditional Approach:
├─ Class Concept
├─ Class Label
├─ Class Reference
├─ Class Hypercube
├─ Class Dimension
└─ Each with different structure and methods
GLOMIDCO Approach:
└─ Class Node (universal container)
├─ Can represent ANY XBRL element
├─ Connections between nodes
└─ Multi-dimensional maps for fast lookup
Benefits:
Important Note:
"Node" is a GLOMIDCO internal concept, NOT an XBRL standard term. XBRL specifications don't use "node" terminology.
DTS = Discoverable Taxonomy Set
The complete set of documents and information needed to understand and use a taxonomy:
DTS Contains:
├─ All schemas (concepts, types)
├─ All linkbases (labels, references, calculations, etc.)
├─ All relationships (parent-child, label-concept, etc.)
├─ All roles (presentation roles, calculation roles)
└─ All dimensional structures (hypercubes, dimensions, members)
After Traversal:
The DTS object contains complete taxonomy knowledge, ready for use.
Problem:
Many different types of XBRL elements:
XBRL Elements:
├─ Concepts (company:Revenue, company:Assets)
├─ Labels ("Revenue", "Umsatz", "Revenu")
├─ References (ASC 606-10-50-12)
├─ Hypercubes (RevenueTable)
├─ Dimensions (SegmentAxis)
├─ Members (RetailSegmentMember)
├─ Role types (presentation role, calculation role)
└─ Resources (footnotes, custom resources)
Traditional Object-Oriented Approach:
...
Problems:
Single Node Class:
Internal knowledge
Benefits:
From Notes:
DTS core structure:
Multi dimensional maps
What This Means:
GLOMIDCO uses multiple indexes to enable fast lookups from different perspectives:
Internal knowledge
Why Multiple Indexes:
Different operations need different lookup patterns:
Trade-off:
From Notes:
Roles contains: Linkbase
Linkbase contains node
Structure:
Internal knowledge
Java Representation:
Internal knowledge
From Notes:
Node could be:
- concept
- roltype
- reference
- label
- resource
- hypercube
- dimension
NodeType Enumeration:
Internal knowledge
Note: Tuples
From notes: "Tuples are also a sort of concept"
In GLOMIDCO, tuples are treated as a NodeType, similar to concepts. Even though tuples are deprecated in XBRL, they're still supported for backward compatibility.
From Notes:
Node -> connectie -> instant... van een ..URC
1 Class whole entrypoint with all from-to relations
Translation: "Node -> connection -> instance... of a URI/URC"
"1 Class for whole entry point with all from-to relations"
Connection Structure:
Internal knowledge
Example Connections:
Presentation Connection:
├─ from: Assets (concept node)
├─ to: CurrentAssets (concept node)
├─ arcrole: parent-child
├─ order: 1.0
└─ linkbase: Presentation linkbase
Label Connection:
├─ from: Revenue (concept node)
├─ to: "Revenue" (label node)
├─ arcrole: concept-label
└─ linkbase: Label linkbase
Calculation Connection:
├─ from: GrossProfit (concept node)
├─ to: Revenue (concept node)
├─ arcrole: summation-item
├─ weight: 1.0
└─ linkbase: Calculation linkbase
Problem:
Different node types have different properties:
GLOMIDCO Solution:
Generic property map:
Internal knowledge
Common Properties by Node Type:
Internal knowledge
From Notes:
Internal knowledge
Translation: "resource (e.g., own constructor to sort things from a linkbase) -> XML fragment in Taxonomy that adds extra validation piece"
What This Means:
Resource nodes can contain custom XML fragments for additional validation:
Internal knowledge
Use Case:
Custom validation rules embedded in taxonomy as XML fragments, processed by GLOMIDCO at validation time.
From Notes:
node does not exist in XBRL terms, node contains connection to label
Key Insight:
"Node" is GLOMIDCO's internal abstraction, NOT part of XBRL specification.
In XBRL Terms:
In GLOMIDCO Terms:
The Abstraction:
XBRL Specification:
├─ Concept defined in schema
├─ Label defined in linkbase
├─ Arc connects them in linkbase
└─ Three separate XML elements
GLOMIDCO Internal Model:
├─ Node (concept)
├─ Node (label)
├─ Connection (arc)
└─ Unified object model
Internal knowledge
Internal knowledge
Internal knowledge
Unified Node Structure:
Traditional Approach:
├─ Concept object: 200 bytes
├─ Label object: 150 bytes
├─ Reference object: 180 bytes
├─ Each with different fields
└─ Total: 530 bytes for 3 objects
GLOMIDCO Approach:
├─ Node object: 120 bytes (base)
├─ Properties map: ~80 bytes per node
├─ Total: ~200 bytes per node
└─ Same structure for all types
Savings: ~40% less memory per element
Multi-Dimensional Indexing Trade-off:
Cost:
├─ Multiple indexes = more memory
├─ Each index: O(n) space
└─ 5 indexes = 5x node references
Benefit:
├─ O(1) lookups from any perspective
└─ Much faster queries
For Large Taxonomy (US GAAP):
18,000 concepts × 200 bytes = 3.6 MB (nodes)
+ 5 indexes × 18,000 refs × 8 bytes = 720 KB (indexes)
+ Connections: ~50,000 × 100 bytes = 5 MB
Total: ~9.3 MB
Worth it for O(1) lookups!
Without Indexes (Linear Search):
Find concept by QName:
├─ Iterate through all nodes: O(n)
├─ For 18,000 concepts: ~18,000 comparisons
└─ Time: ~1-2 ms
Find all labels:
├─ Iterate through all nodes: O(n)
├─ Check type for each: 18,000 checks
└─ Time: ~1-2 ms
Total for multiple operations: Slow!
With Indexes (Hash Map Lookup):
Find concept by QName:
├─ Hash lookup in nodesByQName: O(1)
└─ Time: ~0.001 ms
Find all labels:
├─ Direct access in nodesByType: O(1)
└─ Time: ~0.001 ms
Total for multiple operations: Fast!
1. Flexibility
Adding new node type:
├─ Add to NodeType enum
├─ Define properties
├─ No need to change DTS structure
└─ Easy extension
2. Memory Efficiency
Single structure:
├─ No class hierarchy overhead
├─ No virtual method tables
└─ Compact representation
3. Unified Relationship Model
All relationships through Connection:
├─ Presentation parent-child
├─ Calculation summation-item
├─ Label concept-label
├─ All use same Connection class
└─ Consistent API
4. Fast Lookups
Multi-dimensional indexes:
├─ O(1) by URI
├─ O(1) by QName
├─ O(1) by Type
└─ Fast from any perspective
1. Type Safety
Generic properties:
├─ No compile-time type checking
├─ Must cast at runtime
└─ Potential runtime errors
Solution:
└─ Convenience methods with type checks
2. Memory Overhead
Multi-dimensional indexes:
├─ 5x node references
├─ More memory
└─ But worth it for performance
3. Complexity
Generic structure:
├─ More complex to understand
├─ Not obvious what properties exist
└─ Need good documentation
Solution:
└─ Type-specific documentation and constants
Internal knowledge
Internal knowledge
Internal knowledge
GLOMIDCO DTS Core Structure:
Key Innovations:
Benefits:
Important:
"Node" is GLOMIDCO internal term, NOT XBRL specification term.
From Notes (December 2016):
DTS core structure: Multi dimensional maps
Node -> connection -> instance... of a URI
Roles contains: Linkbase
Linkbase contains node
Node contains concepts, resources or labels
Tuples are also a sort of concept
1 Class whole entrypoint with all from-to relations
node does not exist in XBRL terms, node contains connection to label
Architectural Wisdom:
This design shows sophisticated understanding of:
For Developers:
Understanding this architecture is key to working with GLOMIDCO's internals or designing similar XBRL processors.
This document explains GLOMIDCO's sophisticated DTS core data structure based on December 2016 development notes.