Variables 1.0 Specification Approved to Recommendation

Posted on December 4, 2013 by admin

The XBRL Standards Board and the Formula Working Group are pleased to announce the approval of the Variables 1.0 specification to Recommendation.  Based upon feedback from the community, the previous version was edited to provide clarity to the specification.  There is no intended change in meaning to the previous version of the specification and the schema remains unchanged.


The Specification can be found directly at the link below

• Variables 1.0

The clarification changes in this version are listed below for the benefit of the authors and implementers:
1. 4.2. Added missing error code to be raised when @fallbackValue references fact or general variables: xbrlve:fallbackValueVariableReferenceNotAllowed
No change in meaning – the spec already expressed this requirement.

2. 3.2 Added new error code xbrlve:parameterCyclicDependencies to be raised when there are circular references between parameters.
New validation rule, though for practical reasons all implementations must have enforced this validation previously.

3. 3.2, 3.5.1 The @name of a parameter element may now be used as a global name to reference that parameter in expressions. The parameter may still be referenced by a QName specified on the relationship of the parameter to a resource that makes use of it. In case of clashes, QNames defined on the relationships take precedence over QNames defined on parameter elements. Accordingly this is a backwards compatible change for formula authors.

4. 3.4.1 – Clarification notes on how filter specifications may be defined and implemented. Key points:

  • Filter specifications may be written in terms of implied XPath expressions and require equivalent XPath errors to be reported, however they are actually implemented.
  • It is left to implementations to determine the order in which filters are applied. Formula authors writing expressions in filters must do so defensively so that they can handle any input – they may not rely upon other filters having been applied previously.
  • Implementations of filters should reject facts that do not have the aspects that they are covering.
Other Posts


Would you like
to learn more?

Join our Newsletter mailing list to
stay plugged in to the latest
information about XBRL around the world.

By clicking submit you agree to the XBRL International privacy policy which can be found at xbrl.org/privacy