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.

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.
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
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  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  directory contains a directory called .  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  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 
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. 

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 
�	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. 

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. 

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? 
�	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? 
•	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. 

A.	References

[MML]	Mathematical Markup Language (MathML) Version 2.0 (Second Edition)
W3C Recommendation 21 October 2003
http://www.w3.org/TR/2003/REC-MathML2-20031021/	
[ODF]	ISO/IEC 26300, 2006
Open Document Format for Office Applications 1.0
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html	
[SML]	SpreadsheetML
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]	XQuery 1.0: An XML Query Language
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/	
[XLINK]	XML Linking Language (XLink) Version 1.0
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
Date	Editor	Summary	
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.