Document Purpose: Guide for updating Java XBRL processor from 2014-2016 codebase (GLOMIDCO development stopped December 2016 and has been reactivated Q4 2025)
Target Audience: Providing inside in the GLOMIDCO XBRL processor
Last Updated: January 2026
This document highlights major changes, new specifications, and deprecations in the XBRL standard since December 2016.
GLOMIDCO has halted the development of the Java based XBRL processor in December 2016.
Late 2025 there has been decided to revive the GLOMIDCO XBRL processor
| Year | Major Addition | Impact Level | Priority |
|---|---|---|---|
| 2017 | Inline XBRL 1.1 updates | Medium | High |
| 2018 | Calculations 2.0 | Medium | Medium |
| 2020 | Extensible Enumerations 2.0 | High | High |
| 2021 | Open Information Model | Critical | Highest |
| 2021 | xBRL-JSON | High | High |
| 2021 | xBRL-CSV | High | High |
| 2025 | Report Packages 1.0 | Medium | Low |
| 2025 | Table Constraints (CR) | Medium | Medium |
Good News: No breaking changes to XBRL 2.1 or Dimensions 1.0.
The core specifications you implemented in 2014-2016 remain valid and stable under XBRL International's stability pledge.
The Open Information Model (OIM) is the biggest change since your 2016 codebase. It's a syntax-independent abstraction of XBRL that enables multiple format representations.
OIM calls them "reports" instead of "instances" to be format-agnostic.
Facts in OIM have:
xbrl:conceptxbrl:entityxbrl:period (periodStart/periodEnd/periodInstant)xbrl:unitxbrl:language (for text facts)| Feature | XBRL 2.1 | OIM |
|---|---|---|
| Context | Segment + Scenario | Just dimensions |
| Period | Forever, instant, duration | Only instant, start+end |
| Numeric types | Decimal, float, double, fraction | Decimal only |
| Typed dimensions | Complex types allowed | Simplified |
| Footnotes | Complex linking | Simplified |
Option 1: Add OIM Layer (Recommended)
Input Formats → OIM Core Model → Output Formats
↓
Processing
Validation
Transformation
Option 2: Direct Format Support
Continue with XBRL 2.1/XML, add JSON/CSV as separate parsers (more work, less flexible)
Recommendation: Implement OIM as your internal model. Map existing XBRL 2.1/XML support to OIM, then add JSON/CSV mappings.
JSON representation of XBRL reports, optimized for web applications and APIs.
{
"documentInfo": {
"documentType": "https://xbrl.org/2021/xbrl-json",
"taxonomy": ["https://example.com/taxonomy/2024"],
"period": {
"instant": "2024-12-31"
}
},
"facts": {
"fact1": {
"value": "1000000",
"dimensions": {
"concept": "ex:Revenue",
"entity": "http://example.com/entity/ABC",
"period": "2024-01-01/2024-12-31",
"unit": "iso4217:USD"
},
"decimals": -3
}
}
}
Parser (Input):
Generator (Output):
Same validation rules as xBRL-XML, just different syntax.
CSV-based representation optimized for bulk data and granular reporting.
xBRL-CSV consists of:
{
"documentInfo": {
"taxonomy": ["https://example.com/taxonomy"]
},
"tableTemplates": {
"loans": {
"url": "loans-data.csv",
"dimensions": {
"concept": "ex:LoanAmount",
"period": "2024-12-31",
"entity": "http://example.com/bank",
"unit": "iso4217:USD"
},
"columns": {
"loan_id": {
"dimensions": {
"ex:LoanID": "$"
}
},
"amount": {}
}
}
}
}
loan_id,amount
L001,100000
L002,250000
L003,75000
Parser:
Generator:
Version 2.0 improves how enumerations (code lists) work in XBRL taxonomies.
| Aspect | Version 1.0 | Version 2.0 |
|---|---|---|
| Definition | Concept-based | Domain-based |
| Hierarchy | Single | Multiple inheritance |
| Headusable | Not specified | Explicit attribute |
| Extensibility | Limited | Enhanced |
Instead of concepts, enumerations reference domain members.
Members can be marked headusable to indicate if they're valid fact values.
<xs:element name="CountryDimension"
xbrle:enumeration="{http://example.com}Countries"
substitutionGroup="xbrldt:dimension"/>
Changes Needed:
Version 2.0 is not backward compatible with 1.0, but:
If your processor:
Enhanced calculation validation with better handling of precision and missing facts.
Simple summation with tolerance based on decimals
Enhanced rules considering:
- Decimal precision more carefully
- Missing fact implications
- Rounding expectations
Most 2.1 calculation processors work "well enough" for common cases. Calculations 2.0 handles edge cases better.
Standard format for distributing complete XBRL reports (instance + taxonomy + supporting docs).
report-package.zip
├── META-INF/
│ └── reportPackage.xml
├── reports/
│ ├── report.xbrl (or .json, .csv)
│ └── report.xhtml (inline)
└── documents/
└── supporting-docs.pdf
Only needed if:
Most processors don't need this immediately.
Extension to xBRL-CSV adding constraint expressions for table validation.
Don't implement CR specs unless specifically needed. Wait for REC status.
Updated test cases for XBRL 2.1. Even though spec is stable, tests improve over time.
Updated test cases for Dimensions specification.
These are the same as your 2014-2016 version:
✅ XBRL 2.1 Core - Stable, only conformance suite updates
✅ Dimensions 1.0 - Stable, only conformance suite updates
✅ Formula 1.0 - Stable, no changes
✅ Inline XBRL - Stable, minor refinements
✅ Table Linkbase 1.0 - Stable, no breaking changes
✅ Generic Links - Stable
✅ Versioning - Stable
✅ Taxonomy Packages - Stable
OIM doesn't support:
Note: These still work in xBRL-XML format, just not in OIM/JSON/CSV.
Timeline: 2-3 months
✅ Update conformance testing
🆕 Implement OIM core model
Timeline: 3-4 months
🆕 Add xBRL-JSON support
🆕 Add xBRL-CSV support
Timeline: 2-3 months
🆕 Extensible Enumerations 2.0
🆕 Calculations 2.0 (optional)
Timeline: 1-2 months
Timeline: TBD
Run these test suites:
Test round-trip conversions:
xBRL-XML → OIM → xBRL-JSON → OIM → xBRL-XML
xBRL-XML → OIM → xBRL-CSV → OIM → xBRL-XML
Ensure no data loss in transformations.
Test with current taxonomies:
Consider:
// Old style (2014-2016)
XBRLInstance instance = parser.parse(file);
Context context = instance.getContext("c1");
Fact fact = instance.getFact("f1");
// Modern OIM style
Report report = parser.parse(file);
Stream<Fact> revenue = report.facts()
.filter(f -> f.concept().equals("us-gaap:Revenue"))
.filter(f -> f.period().isInstant());
// Unified API for all formats
ReportParser parser = ReportParser.forFormat(Format.JSON);
Report report = parser.parse(input);
ReportWriter writer = ReportWriter.forFormat(Format.CSV);
writer.write(report, output);
| Task | Estimated Time | Priority |
|---|---|---|
| OIM Core Model | 2-3 months | Critical |
| xBRL-JSON | 1-2 months | High |
| xBRL-CSV | 2-3 months | High |
| Ext. Enum 2.0 | 1-2 months | High |
| Calc 2.0 | 1 month | Medium |
| Report Packages | 2-3 weeks | Low |
| Testing & QA | Ongoing | High |
Total Effort: 8-12 months for comprehensive update
Mitigation: Create new OIM-based API alongside existing API. Deprecate old API gradually.
Mitigation: Benchmark before and after. Optimize hot paths.
Mitigation: Implement formats incrementally. Support xBRL-XML first (existing), then JSON, then CSV.
Mitigation: Run conformance suites frequently. Compare validation results.
Mitigation: Beta releases. Extensive testing with real taxonomies. Clear communication about changes.
✅ Keep your existing XBRL 2.1 + Dimensions implementation
🆕 Add Open Information Model core
🆕 Add xBRL-JSON support
🆕 Add xBRL-CSV support
🆕 Extensible Enumerations 2.0
✅ Update conformance testing
🆕 Calculations 2.0 (if validation is critical)
🆕 Report Packages
🔄 API modernization
🔄 Performance optimization
🔜 Digital Signatures (not yet released)
🔜 Streaming Extensions (not yet released)
🔜 Table Constraints (still CR status)
The XBRL standard has evolved significantly since December 2016, but the good news:
✅ Your core knowledge is still valid - XBRL 2.1 and Dimensions haven't changed
✅ Foundation is stable - No breaking changes to existing specs
🆕 New formats are additive - You can implement incrementally
🆕 OIM simplifies architecture - Better design for multi-format support
📈 Growing adoption - More jurisdictions using XBRL
Good luck with your update! The XBRL community is active and helpful. Don't hesitate to engage with other implementers and XBRL International staff.