Domain Specific Language in JSON for Pricing Formulas

[avajadi]

The current API design uses pseudo-code strings embedded within JSON to represent pricing logic. While this approach maximizes expressiveness, it introduces several practical challenges for implementers:

Technical Issues

• Parser Implementation: Every integrator must build and maintain their own safe evaluator for the embedded DSL
• Tooling Compatibility: Standard data processing tools cannot work directly with string-encoded logic
• Security Concerns: Fetching executable code from third parties requires sandboxing solutions that each consumer must implement independently
• Fragmentation: Each consumer ends up writing a unique parser, which defeats the purpose of having a shared standard

Adoption Barriers

The complexity of implementing a safe DSL evaluator may hinder broader adoption of the standard, particularly for smaller integrators who need a more straightforward implementation path.

Proposed Alternative

We suggest considering a pure structured data approach that eliminates executable strings in favor of declarative data structures. This would:

• Reduce implementation complexity
• Improve security by removing code execution requirements
• Enable standard data tooling to work out-of-the-box
• Facilitate easier validation and testing

Reference Implementation

Norway has successfully implemented a similar approach with their electricity tariff standard, resulting in clean YAML files that describe DSO pricing structures: https://github.com/kraftsystemet/fri-nettleie/tree/main/tariffer

This demonstrates that a constrained, data-only model can effectively cover real-world use cases while maintaining simplicity.

Discussion Points

1. Coverage Analysis: Could a structured data model cover the majority of real-world DSO pricing schemes currently in use?

2. Migration Path: For cases requiring complex logic, could we define a limited set of standard calculation patterns rather than a full DSL?

3. Regulatory Alignment: How does this align with the goal of creating a machine-readable format that supports regulatory requirements?

Context

This feedback comes from practical experience maintaining tariff data for multiple DSOs. While we understand the goal of describing any possible pricing scheme, we believe optimizing for maximum expressiveness may result in a standard that's too complex for widespread practical adoption.

We're interested in participating in further discussions about finding the right balance between expressiveness and implementability.

[avajadi]

The above is some input, edited by me, from the folks at Tibber.

[larwa99]

Does this add anything compared to #61 that was opened in the beginning of March? The CostFunction and PeakFunction is on its way to be removed.