Formula and related specifications:

Candidate Recommendation Overview

Candidate Recommendation dated 2008-03-28

This document:

XBRL-Formulas-Overview-CR-2008-03-28.rtf
is non-normative.

Editors
Geoff Shuetrim geoff@galexy.net Galexy

Contributors

Paul Bull paul.bull@morganstanley.com Morgan Stanley

Jim Richards jdrassoc@iinet.com.au JDR & Associates

Abstract
This document explains the various materials issued as a part of the candidate
recommendation released by the Formula Working Group (FWG). Along with the
specifications and related documents provided with this candidate recommendation, this
overview addresses the specific requirements for achieving candidate recommendation status
as set out in the documentation at:

http://www.xbrl.org/XSB/XBRL_Technical_Working_Group_Processes-Approved-2007-04-
17.htm

Status
Circulation of this Candidate Recommendation is unrestricted. Recipients are invited to email
comments to formula-feedback@xbrl.org, and to submit notification of any relevant patent
rights of which they are aware and to provide supporting documentation.

Formula Specification Candidate Recommendation Overview 2008-03-28

Table of Contents
1Introduction................................................................................................................................................................. 2
2Relationship to existing international standards and related work outside of XBRL International...............................3
3Dependencies with other Working Groups...................................................................................................................4
4Formal objections to the specifications........................................................................................................................4
5Requirements............................................................................................................................................................... 4
6Specifications.............................................................................................................................................................. 5
7Schemas....................................................................................................................................................................... 6
8Examples..................................................................................................................................................................... 6
9Conformance suite tests...............................................................................................................................................6
10Function registry........................................................................................................................................................ 6
11Changes since the previous PWD..............................................................................................................................7
A.References............................................................................................................................................................... 16
B.Intellectual Property Status......................................................................................................................................16
C.Document History....................................................................................................................................................17
D.Approval process..................................................................................................................................................... 17
1 Introduction
This document provides an overview of the Candidate Recommendation (CR) of the formula
and related specifications. It describes the various materials included in the CR.

The CR includes:

 the requirements agreed by the FWG for formula and for XBRL instance validation
against business rules;

 each of the specifications, including normative schemas in appendices;

 non-normative schemas for each of the specifications;

 XBRL function definitions that support the implied XPath expressions in the
specifications; and

 a selection of examples.

A public working draft of the conformance suite for the formula and related specifications will
also be published in conjunction with this candidate recommendation. It is being published
as a public working draft because of the expectation that it will require changes at a more
rapid rate than the specifications themselves as implementation experience accumulates.

2 Relationship to existing international standards and

related work outside of XBRL International
The XBRL Specification [XBRL] provides a syntax for business reports. The XBRL Formula,
Variable and Filter specifications provide a syntax for expressing rules that can be used t
derive new fact values from the data in XBRL business report. These rules are referred to as
formulae. The generic label and reference specifications support labelling of all manner of
different XBRL constructs. In the context of XBRL formulae, they can be used to associate
human documentation with formulae, their variables and the filters that define which facts in
an XBRL business report get selected by a variable for usage in the evaluation of a formula.
The validation and the three assertion specifications define a syntax for expressing rules
about the expected content of business reports, in terms of variables, sets of variables and
formulae.

Together these specifications are intended to support expression of rich formulaic

relationships that can then be communicated between producers and consumers of XBRL
business reports.

The formulae that can be expressed using the syntax defined in theses specifications bears
some comparison to the formulae that can be expressed using spreadsheets and the various
Specifications for expressing spreadsheets as XML (See the SpreadsheetML [SML] and the
Open Document Format [ODF] specifications).

The spreadsheet method of writing formulae relies on spreadsheet coordinates (row and
column identifiers) to identify values that are used as inputs or outputs of a formula. Users
often associate labels with those coordinates to communicate the meaning of the data in the
range of cells identified by the coordinates. Formulae are expressed as operations on values
that are identified by the spreadsheet coordinates or the labels given to those coordinates.

In XBRL, a value in a business report is identifiable by the information associated with that
value. These include the concept that the value measures, the entity that the value
describes, the period over which or at which the measurement was taken, the units in which
the measurement is taken, and, potentially, a range of other aspects given more specificity
in terms of the part of the entity being reported on and the scenario that should be
recognised when interpreting the fact. These aspect values are used in place of co-ordinates
by XBRL formulae when specifying their inputs and outputs.

Formula Specification Candidate Recommendation Overview 2008-03-28

This feature of XBRL formulae comes at a price. Specifically, an XBRL business report can
contain more than one set of facts meeting a specified identification (in terms of a set of
aspect values). In such cases, the response of an XBRL formula processor will depend on
the formula usage pattern. Over time, it is expected that a growing number of usage
patterns will be defined in extension specifications. For now, the response of formula
processors is application dependent.

The XBRL formula specification also addresses another constraint associated with the
spreadsheet method of communicating formulas. In spreadsheets formulae must explicitly
use all of the coordinates to identify each input. XBRL Formulae use implicit matching of
aspect values.

Implicit matching is best described by way of an example. The formula author defines
‘GrossProfit = Sales – CostOfGoodsSold’ in an XBRL taxonomy. This formula is expressed in
terms of inputs that are defined by one aspect: the concept that is measured. No other
aspects are referred to in the formula and so all of the non-referenced aspects are matched
across the variables used in the formula: in this case Sales and CostOfGoodsSold. This
means that the formula can be used to compute GrossProfit for any period, any entity and in
any units so long as both Sales and CostOfGoodsSold are both reported with the same values
for all of those aspects.

Implicit matching reduces the burden on the author of having to explicitly refer to all of the
aspects and dimensions that could be encountered when a formula is processed. This is
particularly important in XBRL, where a formula author may not know all of the aspects or
aspect values that will be associated with facts that will be used as inputs to the formulae
being authored.

The formula and related specifications also bear comparison to XQuery [XQUERY]. Xquery,
especially when supported by a broad range of XBRL specific functions, can be used to
express any of the formulae that can be expressed by the syntax in the XBRL formula and
related specifications. A crucial reason for developing a new syntax for XBRL formulae when
XQuery is already available is that while XQuery programs implementing XBRL formulae may
be excellent for formula execution purposes they do not, in general, provide transparent
documentation of the relationships between the facts or the classes of facts that are
described by formulae. This documentation role for formulae is particularly important for
XBRL where such documentation is crucial to how business choose which aspects to
associate with the facts that they report.
The XBRL specification also bears comparison to MathML [MML]. XBRL formulae are
considerably more mathematically limited than MathML because they express their formulae
using XPath 2.0 [XPATH]. This choice was made in light of the relatively broad and complete
range of implementations of XPath 2.0 compared to MathML.
The validation and assertion specifications (which leverage the formula and related
specifications) bear some relationship to Schematron [STRON] in that they support making
verifiable statements about the content of XML documents. XBRL assertions differ from
Schematron assertions, in that they are specialised to XBRL whereas Schematron is a
language for expressing assertions about patterns in a very broad range of XML documents.
Schematron is so widely useful because it operates well on patterns that are reflected in the
hierarchical structure of XML documents. This strength in Schematron is a handicap when
used with XBRL because many of the important XBRL relationships are expressed using XLink
[XLINK] rather than the XML tree structure. XBRL assertions, by leveraging the aspect
model that underpins formulae and variables, are able to be expressed succinctly and clearly
while still being able to work with the XBRL relationships expressed using Xlink.

3 Dependencies with other Working Groups

There are no changes in the dependencies of these specifications on the product of other
working groups.

4 Formal objections to the specifications

No formal (or informal) objections have been raised in relation to the specifications since the
previous public draft was released.
5 Requirements
The requirements agreed upon by the FWG are included in the CR. There is a document for
formula requirements and a document for XBRL instance validation requirements. These
requirements are accompanied by motivating examples.

These have not been altered since the third public working draft.

The formula requirements are available at:

http://www.xbrl.org/Specification/formula/CR-2008-03-28/requirements/Formula-REQ-CR-
2008-03-28.rtf

The validation requirements are available at:

http://www.xbrl.org/Specification/validation/CR-2008-03-28/requirements/Validation-REQ-
CR-2008-03-28.rtf

The only unfulfilled requirements relate to the ability to generate tuples using formula and
the ability to generate fraction item types using formulae.

The ability to generate tuples is anticipated to be addressed using an extension usage

pattern specification.

The ability to generate output fraction facts may be addressed by a future specification that
specifically targets output facts with fraction data types, if use cases emerge warranting such
a feature. The extension would involve a new formula-type resource with a specifically
designed value production rule to cover numerators and denominators.

6 Specifications
The formula specification has been modularised, resulting in a number of specification
documents.

The specifications in this PWD are:

● Validation

● Consistency assertions

● Value assertions

● Existence assertions

● Formulae

● Variables

● Various filters

● Generic labels

● Generic references

These specifications depend on the March 7, 2008, public working draft of the Generic Link
Specification:

http://www.xbrl.org/Specification/gnl/PWD-2008-03-07/gnl-PWD-2008-03-
07.html

Formula Specification Candidate Recommendation Overview 2008-03-28

Some individuals may find it easier to read the variable specification first, followed by some
or all of the filter specifications. The formula specification and the validation/assertion
specifications may then be more easily understood.

Note that the variable, filter and formula specifications are intended to form building blocks
for more specialised usage patterns. They enable expression of data selection and
transformation rules and data generation rules. In and of themselves, these are useful for
XBRL data selection and XBRL data production. However, they can also be combined to
perform more specialised operations, described within the working group as usage patterns.

The CR only includes specifications to cover one such usage pattern: that being the XBRL
report validation usage pattern. Other specialised usage patterns for formulae and variables
will be addressed in extension specifications while the formula and related specifications are
developing implementation experience. Among these usage patterns, priority will be given
to tuple creation, and formula chaining.

7 Schemas
Some XML documents are also included in the CR. These can all be found in the
http://www.xbrl.org/Specification/formula/CR-2008-03-28/xml directory.

The organisation of these materials on the website is matched by their organisation in the
ZIP file of all materials that is provided along with the CR.

The xml directory contains a directory called core_schemas. This directory contains non-
normative versions of the schemas that support the CR specifications. Each specification
names the schemas that support it. The names of the files in the core_schemas directory
correspond to these schema names.

A non-normative schema for the generic link specification is included for convenience. It will
be omitted when the Generic Link Specification also reaches Candidate Recommendation
status.

8 Examples
More than twenty complete and tested examples are provided with this public working draft,
along with some documentation.

The examples can be reviewed in a web browser by loading :

http//www.xbrl.org/Specification/formula/CR-2008-03-
28/xml/examples/index.xml

9 Conformance suite tests

A conformance suite is currently under development. This contains a broad range of
examples illustrating usage of the specifications. Those with access to the FWG CVS
repository will be able to explore the latest versions of the test cases.

10 Function registry
The XBRL functions used in the formula and related specifications are now defined in an
internal working draft of the XBRL function registry. A PWD of these function definitions and
their associated conformance tests is contained in a zip file that is available at:

http//www.xbrl.org/Specification/formula/CR-2008-03-28/xml/function-
registry.zip
The function_registry.xml file at the root of this collection of function registry files can be
opened in a web browser for readers interested in exploring the function definitions used in
the formula and related specifications to simplify implied XPath expressions.

The function registry has been prepared using the format defined in the Registry PWD that is
available at:

http://www.xbrl.org/Specification/registry-PWD-2008-02-21.zip

11 Changes since the previous PWD

There have been no changes to the feature set or the processing model since the previous
PWD. There have been two syntax changes, some corrections and a number of minor
drafting enhancements.

Detailed documentation of changes since the previous PWD is provided below. Additional
explanations are provided in the revision histories provided in each of the documents.

Diff files generated for the underlying XML documents (as well as the current and previous
XML documents) are provided for those wanting to review the exact modifications made to
the specifications since the previous public release. These are available at:

http//www.xbrl.org/Specification/formula/CR-2008-03-
28/overview/changes.zip

The two syntax changes since the last PWD warrant additional explanation in this overview.

The first syntax change involves the removal of the bindEmpty attribute, with the
specification wording being altered so that the fallbackValue attribute now provids all of the
information that was previously provided by the bindEmpty attribute and the fallbackValue
attribute. This change does not alter the feature set of the variable specification but it does
simplify the variable specification and it makes variable resources less verbose. It also
eliminates a variable validation test that would otherwise need to be run to validate variable
resources.

The second syntax change involves the introduction of a new attribute on dimension filters to
identify whether the dimension being filtered is reported in segments or scenarios. This
clarifies the aspect coverage properties of dimension filters and ensures that their coverage
properties are not dependent on the facts being filtered.

Detailed information about all feedback and responses is provided below. This feedback has
been based upon reading of the specifications and testing of the internal working draft of the
conformance suite by interested software vendors and other stakeholders. The extensive
nature of the feedback, the subtlety of the errors that have been identified and corrected,
and the lack of substantive modification to the specification is all evidence that the
specifications are mature enough to warrant publication as a candidate recommendation.

New features
None.

Removed features
None.

Changed features

Formula Specification Candidate Recommendation Overview 2008-03-28

None.

Syntax changes
Geoff Shuetrim: The dimension filters currently determine the aspect that they can cover
based upon information about the facts being filtered. If a given dimension is used in the
segment for some facts and scenario for others, then a variable that binds as a sequence and
that uses a dimension filter could end up with ambiguous covering properties.

• RESOLVED: A contextElement attribute has been added to the df:dimension element

to indicate whether the filter can cover a segment dimension aspect or a scenario
dimension aspect. This brings the design of the dimension filters fully into line with
the dimensional aspect model and eliminates the potential for ambiguity regarding
which aspects can be covered by a dimension filter.

Morgan Stanley: Variable specification section 3.2: Having both @bindOnEmpty and
@fallback attributes may be redundant. An alternative would be to drop the @bindOnEmpty
attribute and just have the @fallback attribute. It would work as follows, if the @fallback
attribute was not present and the evaluation resulted in an empty set, the evaluation would
not complete. If the @fallback attribute is present and the evaluation resulted in an empty
set, the result would be the value of the @fallback attribute. If binding to an empty set is
permitted the @fallback value would be set to the expression "()” which produces an empty
sequence.

• RESOLVED: Omitted the bindEmpty attribute as suggested. This is an excellent

simplfication of the normative schema and the associated specification explanation
without any loss of expressive power. It also eliminates the potential for nonsense
markup where a variable does not bind to empty sequences but it does have a
fallbackValue attribute.

Corrections
Hitoshi Okamura: The implied XPath expressions using the element test presume a QName
data type for the data type argument of the test but it must be a string.

• RESOLVED: The implied XPath expressions for non-strict concept data-type filters
were changed to replace the element test with a functionally equivalent XBRL
function. This is a reversion to the design of the implied XPath expression for the
PWD 3 except that the XBRL function tests that the data type is derived from rather
than a restriction of the comparison data type. The decision to encapsulate the
element test within a custom function was necessitated by the need to express the
data type in the element test as a string rather than a QName. The conversion from
the QName supplied in the filter to the string representation of it, required to use the
element test, could, in some circumstances, have caused unintended mappings from
one namespace to another, depending upon the in-scope namespace prefix mappings
when evaluating the implied XPath expression.

Geoff Shuetrim: The implied XPath expressions for the strict concept data-type filters
reflect an obsolete design of the XBRL function to access concept data types.

• Resolved The implied XPath expressions were changed to use the XBRL function that
retrieves the QName of the concept data type instead of using the obsolete XBRL
function that only returned a boolean value depending on a test of the concept data
type QName against a supplied QName.
Herm Fischer: The dimension filter specification does not indicate which aspects can be
covered by dimension filters.

• RESOLVED: Restored the statement defining which aspects the explicit and typed
dimension filters can cover. This was accidentally removed during redrafting of the
introduction in late January 2008.

Geoff Shuetrim: Variables specification has a missing reference to the XQuery specification.

• RESOLVED: The reference has been added.

cgh_chen: The xsi namespace prefix is being omitted from the normative schema
appendices.

• RESOLVED: The error in the specification stylesheet was fixed to prevent this
omission.

Hitoshi Okamura: The "false" value of the value attribute on the custom concept attribute
filter should equal fn:false to align to the explanation of the example.

• RESOLVED: The correction has been made.

Geoff Shuetrim and CompSci Resources: There is a stray "or" at the end of the unit
aspect test that should be removed.

• RESOLVED: The correction has been made.

Geoff Shuetrim: The function registry includes functions called facts-segment-dimension-s-

equal2 and facts-scenario-dimension-s-equal2 but the variable specification uses the function
names fact-segment-dimension-s-equal2 and fact-scenario-dimension-s-equal2.

• RESOLVED: The specification is not in line with the function registry.

Hitoshi Okamura: The namespace for the XPath functions should use the 2005 date rather
than the 2006 date.

• RESOLVED: The correction has been made.

Hitoshi Okamura and Herm Fischer: Do we need to define the XPath function namespace
as the default namespace for functions used in explicit or implied XPath expressions? Several
tests in the conformance suite assume that this is the case.

• RESOLVED: A sentence has been added to the XPath usage section of the variables
specification to state that the default function namespace is
http://www.w3.org/2005/xpath-functions. This is consistent with XQery and XSLT
and it means that the fn: prefix is not required for all the XQuery/XPath 2 functions.

Hitoshi Okamura: return needs to change to satisfies in the xpath expression implied by
location filters to ensure that they return a boolean value.

• RESOLVED: Done.

Formula Specification Candidate Recommendation Overview 2008-03-28

Takahide Muramoto: The entity filter examples use the wrong xfi:identifier function name.

• RESOLVED: Fixed.

Takahide Muramoto: The precision filter example uses an invalid minimum precision.

• RESOLVED: Fixed.

Morgan Stanley: There are grammatical errors in the definition of variable-set

preconditions.

• RESOLVED: The grammatical errors have been fixed.

CompSci Resources: Matching Filters Specification: Section 2.3: Paragraph 3: Change

"period" to "unit".

• Done.

CompSci Resources: Variable Specification Section 2.3.2.1: It would be more flexible to

require that all information in a context be partitioned into aspects without specifying any
aspects that have to be there.

• RESOLVED: The unnecessary constraint on aspect models has been relaxed. That
means that content about entities or periods can be treated in more sophisticated
ways by new aspect models. This may become very important as better metadata
about that information becomes available.

Drafting enhancements
cgh_chen: The schemaLocation hints in the normative schemas reference DTDs that can be
difficult to handle for developers. Please omit them.

• RESOLVED: After discussions with Cliff Binstock, the schema location attributes were
removed from the normative schemas.

Geoff Shuetrim: Add specific email (formula-feedback@xbrl.org) for recipients to use when
providing feedback.

• RESOLVED: Done.

Herm Fischer: It is not clear how the segment and scenario filters should work in the
context of the dimensional aspect model.

• RESOLVED: Added a sentence to the introduction (which already focuses on how the
segment and scenario filters are only applicable to non-XDT content, emphasising
that the filters should only be used with variables that are not defined using the
dimensional aspect model.

Andy Harris: The explanation of the conflictingAspectRules error code should include an
enumeration of the kinds of conflicts that can arise.

• RESOLVED: Such an enumeration is not possible because new aspect rules can be
defined and such new aspect rules can conflict with existing aspect rules. Instead, an
example of a conflict is included in the text to clarify.
Morgan Stanley: Variable specification section 2.3.2.1: "All aspect models MUST also
include sufficient additional aspects to ensure that any all content in context segments and
scenarios is also associated with an aspect.” "any" should be "all".

• RESOLVED: Change has been made.

Morgan Stanley: A table summarising the aspects in each aspect model would ease reading
for the variable specification.

• RESOLVED: Done.

Morgan Stanley: Formula specification 2.1.2: The intent of the 4th paragraph beginning
with “An aspect rule addresses ….” is not clear. We recommend the wording be revisited to
clarify what is meant.

• RESOLVED: The main problem in the definition seems to be that it talked about
assistance of applications without spelling out the kind of assistance rendered by an
aspect rule. This terminology has been removed.

Morgan Stanley: Formula specification 2.1.2.6.2: OCC XPath rules: The fact that the
expression is expressed as a @select attribute value should be explicitly stated in the
document.

• RESOLVED: Done. Also clarified the context for evaluation of the XPath expressions
specified by OCC XPath rules.

Morgan Stanley: Formula specification 2.1.2.6.3: The last paragraph in this section says
the “OCC value should be altered according to the OCC dimension rules.” The word “altered”
should be replaced by “overwritten”.

• RESOLVED: Done.

Morgan Stanley: Formula specification 2.1.2.6.3: The example for OCC dimension rules
needs the detail of the OCC dimension rules laid out in the table containing the example.

• RESOLVED: Done.

Morgan Stanley: Formula Spec, section 2.1.2.7: Like OCC, this section is very difficult to
follow and can only be worked out by going through examples of increasing complexity, such
as, where there is just a basic UOM, a new UOM created from the simple UOMs of the inputs
(creating EUR/square meters UOM) and a new UOM created from the complex UOMs of the
inputs (creating a EUR UOM from a EUR/square meters concept and multiplying by a square
meters concept).

• RESOLVED: Additional examples have been provided.

Morgan Stanley: All of the specifications would greatly benefit from more examples. In
particular, examples of usage of the actual syntax. Many of the existing examples are
conceptual rather than syntax. The syntax examples should include both the xml syntax and
a diagram showing how different xml fragments are connected via relationships. These
diagrams would be very valuable since the specification relies very heavily on relationships

Formula Specification Candidate Recommendation Overview 2008-03-28

 • RESPONSE: In several places (OCC aspect rules and unit aspect rules) the examples
have been extended. More generally though, the specifications have included
examples to motivate aspects of the specification and thus reducing them to their
conceptual features rather than their syntax makes them more suitable for their
intended purpose. The specifications have been accompanied by more than 20
complete examples, based on actual use cases. These use the actual syntax defined
in the specification and are deemed by the WG to be superior to inline syntax
examples in the specifications for several reasons. Most importantly, they can be
validated, thus avoiding the kinds of syntax errors that have remained in earlier
specifications for long after recommendation. Also, they are complete and so provide
improved context to assist understanding of the examples. This is not generally
possible with inline syntax examples. WG participants and the broader community
are very welcome to contribute additional examples covering aspects of syntax that
they feel warrant greater coverage. They are also encouraged to provide more
detailed documentation to accompany the existing examples. No changes to the
specification wording will be made in response to this suggestion.

Morgan Stanley: Formula Specification Section 2.1.2.7: What are the implicit and reference
measures in the example?

• RESOLVED: Table notes have been added to the example to explain that implicit
measures are the measures of the implicit unit aspect value and that the reference
measures are the unit measures of the reference unit aspect value.

Morgan Stanley: Formula spec. Section 2.1.2.6.1: The fragment rule example should not
include any XDT mark-up. Doing so confuses the reader. Change the tags in the example.
Dimension rules are properly addressed in section 2.1.2.6.3 OCC dimension rules so it is
misleading to demonstrate how dimensional fragments in the context can be generated in
the OCC fragment rule. The example should show how to generate non-dimensional
information in the scenario or segment parts of the dimension.

• RESOLVED: The statement that the dimension rules are only to be addressed by
occDimension elements is incorrect. To address the concerns and clarify the breadth
of applicability of the fragment rules, additional examples have been provided using
non-dimensional content.

Morgan Stanley: Formula spec. Section 2.1.2.6: The section on OCC rules is extremely
difficult to understand even by experienced XBRL developers and users. The difficulty in this
section is because the notion of the OCC and the construction of the result context from the
OCC rules are very “conceptual”. It requires more explanation in the specification and would
greatly be improved with more examples including the syntax and the transformative
process that occurs. The notion of “original” and “subsequent” OCC was difficult to grasp
until the reader walks through the process. We are proposing that the section be reorganized
with the construction of the fragment rules being brought forward in the section. The process
of building the OCC fragment needs to be reworded to make it clearer how the output of one
rule is the input into the next rule. The determination of the starting point (i.e. empty set vs.
source aspect content) should be made clearer. It would be clearer to define the OCC as the
“set of aspects and their values” instead of just the “aspect values”. This is a subtle
difference, but it seems that this is what the OCC really is.
 • RESOLVED: The examples have been expanded. Examples involving markup are left
to the complete worked examples that accompany the specifications given the
relative level of complexity involved in presenting them in a meaningful manner.
Relevant contributions to those examples are welcomed by the FWG. The suggested
re-ordering of the material has not been done because all of the dry "conceptual"
definitions are required to make the second part, on the various kinds of OCC
fragment rules readable. This has been learned from direct experience with several
previous drafting attempts. Unfortunately the complexity in this section of the
specification does not appear to be avoidable given the XBRL 2.1 and XDT 1.0
foundations that we have to build upon. In practice, an accessible set of reading
materials for OCC aspect rules will need to take the form of a thorough tutorial. To
cast a specification with this complexity in a way that made it a tutorial would carry
too high a risk of error or ambiguity in the definitions being provided and then used.

Geoff Shuetrim: Variable specification definition of a variable set evaluation is not provided
as a complete definition in a single part of the specification, making it harder to get a
complete picture of the definition. RESOLVED: Grouped the various paragraphs contributing
to the definition of a variable set evaluation so that the complete definition is available in a
single place rather than having to be pieced together from different sections of the
specification.

Morgan Stanley: Formula specification: There should be the option of defining a default
source for each aspect.

• RESOLVED: This can be done by using one formula:aspects element for each
different default source that is required.

Morgan Stanley: Formula specification: It is important that the specification explicitly state
that the default aspect MUST not be included in the construction of the output if that aspect
is subject to the XBRL Dimensions 1.0 Specification.

• RESOLVED: The specification already expresses the necessary requirements in

relation to the handling of output OCCs.

CompSci Resources: Formula specification section 1: "This specification defines a syntax

that can be used to document the rules for transforming information obtained from XBRL
reports and their supporting discoverable taxonomy sets into XBRL facts." The word
"transforming" implies changing something. In A + B = C, C isn't a transformation of A and
B, it's an entirely new value, synthesized or generated from A and B. Also wouldn't "instance
documents" be a better word instead of "XBRL reports"?

• RESOLVED: Redrafted as suggested.

CompSci Resources: Formula specification Section 2.1.1: Last paragraph: it's good to have
an introduction to accuracy in XBRL, but the way the first sentence is written could be
misconstrued as a requirement for each formula to have a @precision or @decimals
attribute. A better wording would be "In XBRL, numeric values include information about
their accuracy in the form of a @precision or @decimals attribute."

• RESOLVED: Done. Also moved the paragraph to the front of the next section to
improve the flow of the text.

Formula Specification Candidate Recommendation Overview 2008-03-28

CompSci Resources: Formula specification Section 2.1.1.1: The wording of this section
seems unnecessarily complex. The interaction between the MAYs and MUSTs seems ripe for
confusion and misinterpretation. It would be a good idea to specify the context the xpath
expressions are evaluated in. If the context is explicitly specified, it is done so too far away
to be noticed consistently by implementors.

• RESOLVED: The proposed rewording was adopted. The clarification about evaluation
contexts was incorporated.

CompSci Resources: Formula specification Section 2.1.2.1: Why can't the uncovered
QName be used in explicit filtering? It's not obvious on the first reading. To improve clarity
why not re-arrange to be: 1. Definition of uncovered QName; 2. Determination of source for
uncovered QName; 3. Implicit filtering ensures identical SAV; 4.
xbrlfe:illegalUseOfUncoveredQName. I also propose that the
xbrlfe:illegalUseOfUncoveredQName error code paragraph explain better why the error is
required. Also define the term "Implied SAV".

• RESOLVED: The uncovered Qname is specifically designed to give users access to

implicit aspect values. While we could just treat it as a variable name when doing
explicit filtering and only give it a special meaning when doing implicit filtering, this
was deemed to be overly complicated. The re-organisation of the paragraphs and the
new definition and the additional error code explanation have all been done.

CompSci Resources: Formula specification Section 2.1.2.2: First paragraph: No, formulae
always have default aspect rules. They're just not always applied. Remove the MAY.

• RESOLVED: Done.

CompSci Resources: Formula specification Section 2.1.2.5: The second sentence, "A period
rule specifies its RAV in terms of variations on its SAV.", is not true. It is only based on the
SAV when there are no child elements (in which case the variation is the empty set).
Otherwise, it is not based on the SAV at all.

• RESOLVED: The sentence was deleted.

CompSci Resources: Formula specification Section 2.1.2.6.2: The context element for the
XPath expression is not specified.

• RESOLVED: It is now specified.

CompSci Resources: Variable specification Section 1: It is not clear to the reader exactly
what parameters are and how they differ from variables. A definition in this section would be
very helpful. The current definition of "parameter" is "A parameter is declared by a element,"
which doesn't actually say anything about what a parameter actually is, just what its syntax
is. "Filters" and "aspects" should also be defined here. "Covering" might also be good to
define here. CompSci Resources: Variable Specification Section 1.7.2: The only normative
reference I can find for the very important point that parameters are values that are supplied
to the processor from the outside (ie, from a user instead of extracted from the XBRL) is in
Section 3 of the Formula specification, which isn't even referenced by this document.
Paragraphs 5 and 6 may have been intended to express this, but it's unclear what is meant
by "processing application" and how it differs from the "formula processor". At any rate, it
would make the this part of the spec much easier to read if that was earlier in the document.

• RESOLVED: Links to terms have been added to the introduction. The definition of
parameters has been given the necessary substance. Filters, aspects and covering
remain omitted from the introduction given their relatively technical nature.
CompSci Resources: Variable specification Section 1: Paragraph 7: "within" is one word,
not two. Also, the entire paragraph is unclear. The wording of the paragraph has been
revised to improve clarity.

CompSci Resources: Variable specification Section 1.1: We've been using XQuery with raw
XBRL docs for a year now without the need for any special stuff. It might be clearer to
mention that these functions do make it easier to read XBRL-related XPath expressions, but
it is still a pretty straightforward process to use XPath without them. XQuery reference is
broken, at least in HTML version.

• RESOLVED: The reference was fixed in response to other feedback. The motivation
for a library of XBRL custom functions now incorporates mention of supporting DTS's.

CompSci Resources: Variable Specification Section 1.7.1: It might be a good idea to

mention here that the definition of the implementation of the custom function is outside of
the scope of the spec.

• RESOLVED: Done.

CompSci Resources: Variable Specification Section 1.7.2: Paragraph 3: Perhaps "variable

processor" would be a better choice here, since presumably this spec can be built upon for
non-formula processing.

• RESOLVED: Done.

CompSci Resources: Variable Specification Section 1.7.2: Paragraph 6: To avoid potential

misreading, add "Otherwise," to the beginning of this sentence.

• RESOLVED: Done.

CompSci Resources: Variable Specification Section 2.2.1: "Aspect" is being used here
without first being defined. To "cover" is used here without being defined. This makes it hard
to understand why a filter would take an aspect into account without "covering" it, or why a
formula author would wish for that to happen. It also brings to mind the question if a filter
can cover an aspect it doesn't take into account (it cannot according to a later section, but
this is not apparent at this point to the reader.)

• RESOLVED: Sections have been rearranged to ensure terms are not used before they
have been defined.

CompSci Resources: Variable Specification Section 2.2.1: "Explicit filter" is used here
without being defined.

• RESOLVED: Removed the word explicit.

CompSci Resources: Variable Specification Section 2.3.2: Are aspect tests intended to
always be equivalence relations in the mathematical sense of the term? (ie, symmetric,
transitive, and reflective) If so, this should be explicitly stated. If not, the difference between
the two facts needs to be made clear.

• RESOLVED: They are now explicitly identified as equivalence relationships.

Formula Specification Candidate Recommendation Overview 2008-03-28

CompSci Resources: Existence Assertions Specification: It should be mentioned
somewhere that the @strict attribute in the Consistency Assertions Specification can also be
used for asserting existence, if a consistency assertion is also desired.

• RESOLVED: This has been mentioned in the abstract.

CompSci Resources: Implicit Filters Specification: Several of the other specifications

mention implicit filters without depending on this specification. Notable among them is the
Variables Specification.

• RESOLVED: The variable specification linked to the implicit filter when it used
terminology defined in that spec. It now also explicitly references the spec in the
implicit filtering section.

CompSci Resources: Implicit Filters Specification Section 1: Paragraph 4 is a little hard to

digest.

• RESOLVED: The paragraph has been broken into three paragraphs.

CompSci Resources: Implicit Filters Specification Section 1: Example 1: The "concept

matching filter" and "period matching filter" links are broken, at least in the HTML version.

• RESOLVED: The URL of the variable specification has been updated.

CompSci Resources: Implicit Filters Specification Examples 2 and 3 The meaning of these
tables is completely unclear. It seems like the "Filters" column is the list of explicit filters,
and it's missing a column indicating what the implicit filters would be.

• RESOLVED: Added an explanatory paragraph for each example.

CompSci Resources: Relative Filters Specification: "Relative Filter" is a misleading name.

Given the strong presence of XPath in these specifications, the name leads to the natural
assumption that it is filtering on having some kind of specified XPath traversal relationship,
which is what the Location filter does. In fact, "Relative" would be a better name than
"Location" for that filter.

• RESOLVED: The introduction has been augmented to clarify this issue.

CompSci Resources: Relative Filters Specification: After reading this short, example-free
specification once, I'm not certain at all what this filter is supposed to do.

• RESOLVED: The specification has two examples. Explanatory text has been added to
the examples to improve the motivation.

Takahide Muramoto: The fn:false function in the implied XPath expression for the precision
filter is missing its brackets.

• RESOLVED: Fixed.

Takahide Muramoto: The xfi:is-fraction() function in the implied XPath expression for the
precision filter has the wrong prefix.

• RESOLVED: Fixed.
Takahide Muramoto: The explanation of the precision filter describes it as a "greater than"
test but the XPath expression is "greater than or equal".

• RESOLVED: The text now aligns with the implied XPath expression.

Other comments
Herm Fischer: XPath does not provide guarantees that there is no short-circuit evaluation
of XPath expressions (where the second argument for an and or or operator is not evaluated
because of the result from evaluating the first argument). The aspects covered by some
filters are determined dynamically, by evaluating XPath expressions. The specifications need
to clarify that the XPath expressions required to be evaluated to determine what aspect a
covering filter covers have to be evaluated if the filters are required to cover one or more
aspects.

• RESOLVED: No changes are required. The determination of the aspect covered by a

filter already clearly needs to be determined during evaluation of a variable if the
specification is going to be correctly implemented by processing software. Moreover,
the kinds of short-circuit evaluations that could cause problems are all associated
with the XPath expressions implied by variables (and their filters). These are not the
expressions that need to be evaluated for dynamic determination of covered aspects.

Morgan Stanley: How are new aspects defined?

• RESOLVED: They are defined in new extension specifications. Guidance on what

these extension specifications must contain is provided in section 2.3.2. There is also
relevant information on defining new aspect models in section 2.3.2.1.

Morgan Stanley: Variables specification section 2.3.3: Can preconditions (2.3.3) be linked
to variables within a variable-set? How would one accommodate independent preconditions
that attach to variables within a variable-set?

• RESOLVED: Preconditions can only be associated with variable sets, not with
variables. Independent preconditions (relating to variables in a variable set) each
have to be associated with the variable set itself. The motivation for this approach is
that variable evaluations achieve nothing without resulting in a variable set
evaluation. Tying a precondition to a variable achieves nothing in terms of processing
outcomes.

Morgan Stanley: In variable specification section 1.7.2: sequence constructors are excluded
from declaring default parameter values. Why is it necessary to exclude this process given
that it is an XSLT construct.

• RESOLVED: Parameters have a syntax that closely parallels that of parameters in the
XSLT 2.0 specification. However, they are not XSLT 2.0 constructs. Sequence
constructors in XSLT 2.0 parameters define supplied parameter values that are
singleton sequences containing a single implicit document node with a set of children
elements defined by the content of the parameter element. Requiring software to
produce this kind of construct, without having any motivating use cases, has been
avoided because of the extent to which it biases formula processing solutions toward
being an application of XSLT 2.0.

Morgan Stanley: Formula Specification Section 2.1.1.1: Why are precision and decimals
child elements rather than attributes on formula resources?

Formula Specification Candidate Recommendation Overview 2008-03-28

 • RESOLVED: So that we use XML Schema to enforce the constraint that a formula
MUST NOT contain both.

Morgan Stanley: Formula Spec section 2.1.2.1: Change “A segment SAV is a SAV that is
reported by a segment or the absence of a a segment" to “A segment SAV is a SAV that is
reported by a segment or by a segment that has no content i.e. an empty set.” Make the
same changes for scenario.

• RESOLVED: Empty segments and scenarios (those with no content) are prohibited by
the XBRL 2.1 specification and the suggested rewording has the potential to mislead
readers into ignoring this constraint.

Morgan Stanley: Variable Specification: The rules for determining the composition of the
result sequence are unnecessary. The resultant sequence should always be the source
sequence, if the @bindAsSequence is set to true(). Forcing all the uncovered aspects to have
equivalent aspect values per aspect is not the desired behavior. For example, assume an
instance has monthly product segment sales information for a year and the formula author
wishes to calculate the average sales for the year by product segment. This could be
achieved by creating a sequence of monthly sales figures for the year by segment and
passing the sequence to an average function. Using the specification as written the author
would have to specify two filters, one for the product segment and one for the date period. If
the author did not specify the date range filter the sequence would not evaluate because the
date aspect would not have equivalent values. However, if the specification did not enforce
the “equivalent value” constraint the sequence would evaluate because if would include all
values on the date aspect. Formula specification: In determining the SAV implied by a
source, for a given aspect rule, where the source equals the uncovered QName we believe
that only variables that have evaluated to a singleton are valid sources for aspect values. If
the uncovered aspects in a sequence have equivalent values per aspect then whether the
sequence is a singleton or larger is not important. However, we submit that forcing
sequences to have equivalent values per aspect on uncovered aspects is unnecessary and
contrary to the desired behavior (see bindAsSeqeunce in XBRL Variable 1.0 comments
above). Formula specification: We propose that the constraint of forcing uncovered items in
sequence variables to have equivalent values per aspect be removed from the specification.
Further, we propose that a constraint be imposed that only singletons be regarded as valid
sources for SAV for uncovered aspect in aspect rules. The error code
“xbrlfe:defaultAspectValueConflicts” is unnecessary if sources are restricted to variables that
can only be bound to singletons. There should be the option of defining a default source for
each aspect. It is also important that the specification explicitly state that the default aspect
MUST not be included in the construction of the output if that aspect is subject to the XBRL
Dimensions 1.0 Specification.

• RESOLVED: The specification will not be changed. The motivating formula assumes a
predefined content in an instance document, which is misleading in that it allows
shortcuts in the formula definition. If the suggested formula were applied to an
instance with information from two years, should it produce the average value over
the two years or the average value for each year? What would happen if we apply
this formula to an instance with information in different currencies? The behaviour
defined in the third and fourth public working drafts assures that the facts combined
in a sequence are those defined by the formula author, no matter the content of the
instance document, and thus, improving transparency, intuitiveness and reusability.
The proposed change would render cross-dimensional aggregation formulae (used
profusely in FINREP and COREP taxonomies) considerably more difficult to express
when the content of the target instance is not known a priori.
Morgan Stanley: Variable specification section 3.2: Deeming a variable-set to being “not
evaluated” if all variables in the variable set evaluate to fallback values or empty sets is not
appropriate (last paragraph in this section). If all of the evaluation conditions have been met
then the variable-set DOES evaluate. The fact that the result is empty sets and/ or fallback
values only does NOT invalidate the evaluation. A variable-set does not evaluate when the
evaluation process cannot complete. Deeming certain normal conditions as “failed” appears
to be an unnecessary and arbitrary constraint.

• RESOLVED: The specification will not be changed. The main purpose of the variable
specification is to define selections of the information in target XBRL instances.
Relaxing the constraint as suggested results in a move away from this underlying
design and has unappealing consequences. In particular it would prevent existence
assertions from being able to count variable-set evaluations when testing for the
existence of specific categories of facts in the target XBRL instance. For this reason,
the constraint is definitely not arbitrary or unnecessary. As an aside, it should be
noted that the specification still permits formulae to produce facts with no target
XBRL instance inputs by using an empty variable set and preconditions (or just using
general variables).

CompSci Resources: Overview document: The explanation of usage patterns needs more
detail. Right now it appears to be in conflict with the capabilities of the formula specification.

• RESOLVED: A paragraph has been added. Usage patterns have been explained in
detail and formula capabilities have been directly referenced.

CompSci Resources: Formula specification Section 2.1.1.1: An example with both accuracy
rule attributes would make a good addition. Alternatively, the section could be simplified by
requiring that only one of the accuracy rule attributes can be used.

• RESOLVED: This is not allowed by the XML Schema constraints. Note that the
accuracy rules are expressed as child elements and there is a choice between them.

CompSci Resources: Formula specification Section 2.1.1.1: It would be very instructive at

this point to have an example that actually computes the appropriate precision for a formula
given the precision of its inputs.

• RESOLVED: Formulae are poor at preserving accuracy information about inputs in

output fact accuracy. The existing accuracy rules may be useful for this kind of
preservation on the very simplest of formulae but in general cases accuracy
information about inputs will be lost. For this reason, examples encouraging such
expectations of accuracy rules are not included in the specification. See
http://en.wikipedia.org/wiki/Significance_arithmetic for details of the complexity
involved in doing the suggested kind of accuracy rule correctly.

CompSci Resources: Formula specification Section 2.1.2.1: "Output aspect value" would be
clearer than "required aspect value".

• RESOLVED: This change has not been made because the term output aspect values
is already used. Maintaining a distinction is important given that the representation
of the output aspect value can potentially differ from the representation of the
required aspect value given features like the default values for explicit XDT
dimensions.

CompSci Resources: Variable Specification Section 2.2.1: Can more than one filter cover
the same aspect in a situation where more than one filter applies?

Formula Specification Candidate Recommendation Overview 2008-03-28

 • RESOLVED: Yes - the specification imposes no constraints on this kind of construct.
That said, in practice, covering filters will generally tie an aspect down to a single
value and so having two of them will not be particularly useful.

CompSci Resources: Variable Specification Section 2.3.2.1: It seems painful to have to

have a new specification to create a different aspect model. Wouldn't it be better to just
make such things loadable programmaticly, especially since they are just relatively simple
XPath expressions?

• RESOLVED: It is only that simple if it does not involve new aspects. Unfortunately,
most new aspect models will require new aspects to be defined.

CompSci Resources: Variable Specification Section 2.3.3 Typo in first paragraph. Should be
"defined conditions".

• RESOLVED: Already fixed in response to other feedback.

CompSci Resources: Variable Specification Section 2.3.2.1: Can more than one aspect in
an aspect model take into account the same information? If not, it sounds like the example
in the first paragraph of separating entity identifier scheme and value into separate aspects
cannot be done because it would conflict with the requirement to have an entity-identifier
aspect. On the other hand, allowing the same information to be used in the aspect test for
more than one aspect seems like it could lead to problems, including indeterminate behavior.

• RESOLVED: Two aspects in an aspect model can take into account the same
information. No indeterminacies have been identified in relation to this feature.

CompSci Resources: Boolean Filters Specification: It would be useful to be able to specify

whether the set of covered aspects is the intersection or the union of the sets of aspects
covered by the component filters. The most reasonable defaults seem to be union for the
And filter and intersection for the Or filter.

• RESOLVED: This was considered in earlier internal working drafts but was not
sufficiently well supported by use cases to warrant the complexity. If such features
are found to be useful in practice, then they may be covered in future filter
specifications.

CompSci Resources: Concept Filters Specification Section 2.6 @direct would be a more
accurate name for the attribute than @strict, since strictly speaking, the types not matched
when @strict is false are still members of the substitution group.

• RESOLVED: So long as the specification of the attribute is sufficiently clear, the

distinction in meaning of the attribute does not warrant the syntax change at this
stage of development.

CompSci Resources: General Filters Specification: It seems a little harsh to not be able to
cover anything with the General Filter. Consider giving the ability to specify covering aspects
through some attribute or nested element.

• RESOLVED: This is quite a substantial request given that it then requires all aspects
to have their own unique identifier that can then be specified on filters. This was
considered in earlier internal drafts (for all filters) and was rejected because of its
impact on the people trying to define fact variables.
CompSci Resources: Period Filters Specification: What about a filter for periods that are
before or after a specified date? You would want an attribute specifying whether both the
start and end of a duration need to be before (after) that date. For convenience, there could
also be a variable attribute that could be used to use a variable set to an instant for the date
to compare to. It would also be convenient to have a filter for matching periods between two
certain times. The boundary attribute could be set to {start, end, both, either} for
determining if the start or end of a duration is required to be between the two times. There
could be a variable attribute that takes a duration and uses it for the dates to be between.

• RESOLVED: We expect to encounter many new ideas for filters and hope to publish
new specs for filters subsequent to the publication of the existing set of materials.
This particular suggestion seems to tie in well for a new period filter spec that
enables period filters to leverage a range of metadata about how the time dimension
should be discretised for computational purposes.

CompSci Resources: Tuple Filters Specification: "Relative Filter" would be a better name
for the Location filter. Perhaps "Relative Location" would be best.

• RESOLVED: The difference in clarity to be achieved from the renaming of the filter
and the likely associated syntax consequences does not warrant the change at this
stage of proceedings.

Formula Specification Candidate Recommendation Overview 2008-03-28

 A. References

Mathematical Markup Language (MathML) Version 2.0 (Second Edition)

[MML]
W3C Recommendation 21 October 2003
http://www.w3.org/TR/2003/REC-MathML2-20031021/
ISO/IEC 26300, 2006
[ODF]
Open Document Format for Office Applications 1.0
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
SpreadsheetML
[SML]
http://www.spreadsheetml.com/
[STRON] ISO/IEC 19757-3, 2006
Document Schema Definition Language (DSDL) -- Part 3: Rule-based
validation -- Schematron
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
XQuery 1.0: An XML Query Language
[XQUERY]
W3C Recommendation 23 January 2007
http://www.w3.org/TR/xquery/
[XBRL] Extensible Business Reporting Language (XBRL) 2.1 Recommendation with
corrected errata to 2006-12-18.
http://www.xbrl.org/SpecRecommendations/
XML Linking Language (XLink) Version 1.0
[XLINK]
W3C Recommendation 27 June 2001
http://www.w3.org/TR/xlink/
 B. Intellectual Property Status
This document and translations of it may be copied and furnished to others, and derivative
works that comment on or otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may not be modified in any way,
such as by removing the copyright notice or references to XBRL International or XBRL
organizations, except as required to translate it into languages other than English. Members
of XBRL International agree to grant certain licenses under the XBRL International
Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and
XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or
adoption of XBRL International specifications may require use of an invention covered by
patent rights. XBRL International shall not be responsible for identifying patents for which a
license may be required by any XBRL International specification, or for conducting legal
inquiries into the legal validity or scope of those patents that are brought to its attention.
XBRL International specifications are prospective and advisory only. Prospective users are
responsible for protecting themselves against liability for infringement of patents. XBRL
International takes no position regarding the validity or scope of any intellectual property or
other rights that might be claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any effort to identify any
such rights. Members of XBRL International agree to grant certain licenses under the XBRL
International Intellectual Property Policy (www.xbrl.org/legal).

C. Document History
Summary
Date Editor
2008-02-14 Geoff Shuetrim First draft.
2008-02-19 Geoff Shuetrim Added section on relationship to other
specifications as required for a last call for
comments, drawing on extensive drafting by Paul
Bull.
2008-02-20 Geoff Shuetrim Incorporated editorial feedback from Jim
Richards.
2008-03-12 Geoff Shuetrim Updated for CR release.
2008-03-13 Geoff Shuetrim Incorporated feedback from CompSci resources.

D. Approval process
This document will not be released as a part of any final recommendation.

Formula Specification Candidate Recommendation Overview 2008-03-28