Formula PR
From XBRL
[edit] Feedback and resolutions
[edit] Issues requiring resolution
[edit] Responses pending approval by FWG
[edit] None.
[edit] New features
[edit] None.
[edit] Removed features
[edit] None.
[edit] Changed features
[edit] None.
[edit] Normative Corrections
[edit] None.
[edit] Other comments
[edit] CGH Chen 2009-05-07 xfi:nodes-corresond() function parameter type error
In function registry:
the parameter type node() should be changed to node()*
Please see xfi:fact-segment-remender ... and the aspect test expression. non-XDT segment aspect test: xfi:nodes-correspond(xfi:fact-segment-remender($aspectTest:a), xfi:fact-segment-remender($aspectTest:b))
xfi:fact-segment-remander(schema-element(xbrli:item)) return element(*)*
- Herm 2009-05-07: although the function could be modified (in PR?, sending us back to CR?) it was not the intent to compare sequences. Anyway XPath is only for explanatory purposes, as most people would implement this stuff in Java. I'd suggest changing the XPath to:
for $remainder-a in xfi:fact-segment-remainder($aspectTest:a),
$remainder-b in xfi:fact-segment-remainder($aspectTest:b) return
((count($remainder-a) eq count($remainder-b)) and
(every $i in 1 to count($remainder-a) satisfies
xfi:nodes-correspond($remainder-a[$i],$remainder-b[i]) ))
[edit] CGH Chen 2009-05-07 suggests new context-comparing function
c-equal using s-equal compare segment and scenario. but when formula using dimensional aspect model construct a new output fact, the output diemsions order (in the segment or scenario) may be different.
When we implementing the formual processor, we found the output instance is differ to the expected result instance. I think: should define a new function to the function registry. so that compare the two context an return true.
- Herm: 2009-05-06: s-equal is not intended to compare dimensional contexts. The dimensions spec, now in great debate, long ago defined s-equal2, but the dimension working group resolutions and issues in progress make that s-equal2 wrong for the purposes you desire. What is needed is to compare the non-XDT segment and non-XDT scenario portions, and then for each dimension experienced by the item, compare the dimensional values (because they are no longer required to be in the same container, seg/scen, as each other, and may be defaulted).
- However to expect a single function to compare two items, one in the input instance and other in the output instance, requires the multi-instance features discussed in the extension pattern implementation for multi-instance (on wiki only) and the tentative IWD 90601 formula directory. If formula functions were to be used to compare even dimensions experienced across the two instances, then these post-Rec multi-instance issues need to be implemented, e.g., an extension beyond PR functions and PR concepts for determining dimensional experiences across independent separate instances.
- I've added suggestion for this function to the multi-instance wiki discussion page.
[edit] 20090506 RH reported by Lukasz Wycisk
[lukaszwycisk@yahoo.com] on xbrl-dev
Variables 1.0 documenation chapter 2.2 (aspectmodels) just above table2 mentions that the non-XDT segment and scenario are the OCC for the dimensional aspect model ... Looks this states the exact opposite of what is meant. Error continues in table2.
- Herm: 2009-05-06: I have attempted to explain on xbrl-dev. I don't see any error in the spec, or even any need for wording change, it is appropriately precise and devoid of the sort of explanation that comes in oral back and forth discussion. (People need the human touch to really get this stuff because each reader comes from a different set of life experiences, language, and software background.) I think the these correspondents didn't catch the point that we clearly distinguish complete-seg/scen aspects for non-dim aspect model, vs. one-by-one dimensions and non-XDT aspects for dim aspect model.
[edit] CGH Chen: 2009-05-03 Spec typos
Variable spec typed dimension error 2.2 aspect models A scenario OCC aspects, is the occ aspect with a value given by the remainder of the scenario. NOT segment, copy error.
3.4.1 Filters has changed "target fact" to "input fact" paragraph 2, but not changed complete in sentence 3: Filters express criteria that can be applied to target facts
- Herm: 2009-05-03: fixed typos.
the implied XPath expression have errors for XPath 2.0 /XQuery 1.0: IfExpr, if (..) then ExprSingle else ExprSingle In the period filters 1.0 missing then clause.
- Herm: 2009-05-03: added then (false()) to these situations
variable 1.0 and entity filter 1.0 not consistent: xfi:identifier-value and xfi:item-identifer-value
- Herm: Variable spec entity identifier aspect XPath adjusted function names to match function registry; Entity filter spec, adjusted function names to match function registry (xfi:item-identifier-* changed to xfi:fact-identifier-*).
[edit] Herm: 2009-04-22 core-schemas have elements with embedded complex types, instead of complex types that are usable by future extensions
In developing several of the extemsion prototypes I've had to completely copy core schema elements instead of substiting for them.
For example, to extend the variables.xsd function definition signature (to add the xpath implementation extension) I couldn't just do a substitution for it, because the function element contains its complex type. If it were made a type instead, that could be substituted for.
Or another example, the concept filter extension proposal needs to extend the conceptName (to add a conceptTest to the qname and qname expression choices), and perhaps reuse some of these building blocks in making the conceptRelation filter. They'd have to also split the complexType into a type, not embedded in the element.
This change would have no impact on the PR spec, or on any implementation or conformance test function.
