Understanding the Paradigm Shifts
ISO 19135:2026 introduces four fundamental conceptual changes from the 2015 edition. Understanding these shifts is essential before planning your migration.
Two-Plane Architecture
The most significant architectural change: separation of meaning from data.
What Changed
2015 Edition
Single plane containing register items with embedded semantics.
2026 Edition
Two distinct planes with explicit relationships.
Why It Matters
This separation enables:
- Independent evolution: Concept definitions can change without affecting stored content
- Multiple representations: The same concept can be represented in different formats
- Schema flexibility: Data structures can evolve while preserving semantic meaning
- Better governance: Concepts and content can have different lifecycles
Migration Implications
What You Need to Do
- Extract concepts: Identify the semantic meaning behind your existing register items and create corresponding concepts in the concept plane
- Define relationships: Link your content to concept versions
- Decouple schemas: Separate your data schemas from semantic definitions
Note: For a Governed Content Register (the 2015 equivalent), you can treat the concept plane as implicit—concepts exist but don't need explicit management.
Capability-Based Conformance
Moving from a fixed hierarchy to modular capabilities you choose based on needs.
What Changed
2015 Edition
Three hierarchical conformance classes:
2026 Edition
Modular capability-based register types:
Why It Matters
- Flexibility: Add only the capabilities you need
- Incremental adoption: Start simple, add features later
- Clearer compliance: Each capability has explicit requirements
- Better testing: Modular test suites for each capability
Migration Implications
Mapping Your Conformance Class
| 2015 Class | 2026 Type | Reason |
|---|---|---|
| Core | Content Register | Basic content management capabilities |
| Extended | Governed Content Register | Governance capabilities without explicit concepts |
| Hierarchical | Governed Concept Register or CCR | Concept hierarchy capabilities needed |
Commitments Framework
Explicit promises about access, persistence, and transparency that registers make to users.
What Changed
2015 Edition
- No formal commitments framework
- Implicit assumptions about persistence
- Governance defined but not service levels
2026 Edition
- Three commitment categories
- Multiple levels within each
- Explicit declarations required
Commitment Categories
Access Commitments
- Metadata access: Metadata accessible via identifiers
- Content access: Actual content always accessible
- Historic access: Change history always accessible
Persistence Commitments
- Identifier persistence: Identifiers never change (basic)
- Metadata persistence: Can rewind metadata state
- Content persistence: Can rewind content state
- Append-only: Nothing ever removed
Transparency Commitments
- Metadata transparency: Change metadata available
- Content transparency: Content changes available
- Historic transparency: All changes available
Migration Implications
What You Need to Do
- Review your current service levels
- Determine which commitment levels you can support
- Document commitments in your register specification
- Implement any missing capabilities
Minimum: You must at least declare identifier persistence (level 1) for any compliant register.
Technology Neutrality
No prescribed implementation technology—focus on capabilities, not encodings.
What Changed
2015 Edition
- Normative XML schema provided
- Specific data model in UML
- Implementation details in normative sections
- ISO/TS 19135-2:2012 for XML encoding
2026 Edition
- No normative XML schema
- Conceptual model only
- Focus on capabilities, not implementations
- Any encoding technology acceptable
Why It Matters
- Implementation freedom: Use JSON, XML, RDF, databases, or any technology
- Future-proof: Not tied to specific technologies that may become obsolete
- Modern architectures: Supports REST APIs, graph databases, etc.
- Reduced complexity: Focus on what you need, not prescriptive schemas
Migration Implications
Breaking Change for XML Implementations
If your 2015 implementation uses the normative XML schema:
- The 2026 edition provides no replacement schema
- You can continue using your existing XML schema
- Consider this an opportunity to evaluate other technologies
- ISO/TS 19135-2:2012 was withdrawn in 2019
Positive Impact
Technology neutrality means you're not forced to change your underlying technology:
- Existing XML implementations can remain (just not normative)
- Database implementations are equally valid
- JSON-based APIs are fully compliant
- Graph databases can be used effectively