FpML Issues Tracker
closed
Minor
Have not tried
Validation Rules
Admin
None
Summary
The new HTML layout is largely fine, but has some problems where it doesn't match the spirit or letter of what was agreed.
Problem #1 The first problem is the guard on the context is given in the body of the rule and not the context. This disassociated the guard from the context and also runs the rule and the guard together, but they need to be distinguished.
The solution is to give the guard on the context, not the rule.
Problem #2 We agreed to use the term "Precise Description" not "Formal Description". This was changed in the agreement document in its last revised form before agreement. It is important as the XPath descriptions are not formal, but they are precise.
The solution is to use the label "Precise Description" instead of "Formal Description".
Problem #3 The context should be written out in XPath for the precise description. For example instead of "Sandwich (complex type)" we should have "element(*, Sandwich)".
The solution is to write the context out in XPath in the precise description.
An example of all the changes is: " ird-16 (Mandatory) Context: CalculationPeriodDates (complex type) Formal Description: [exists(//element(*, CalculationPeriodDates)/firstRegularPeriodStartDate)] terminationDate/unadjustedDate gt firstRegularPeriodStartDate "
becomes: " ird-16 (Mandatory)
Precise Description: Context: element(*, CalculationPeriodDates)[exists(//element(*, CalculationPeriodDates)/firstRegularPeriodStartDate)] Rule: terminationDate/unadjustedDate gt firstRegularPeriodStartDate
English Description: Context: elements of type Calculation Period Dates that contain as a descendant an element of type CalculationPeriodDates containing a child firstRegularPeriodStartDate Rule: unadjusted termination date must be after the firstRegularPeriodStartDate
Comment: The termination date must be after the start date. "
Notes:
lyteck
12/09/08 6:32 pm
Problem #1:
If the guards are to be tied to the context (i.e., in the HTML, located right after the context, and not tied to either the English or Formal descrptions), should the guards be repeated in the English Description in plain English? This is an issue because some of the guards, expressed in XPATH can be difficult to understand.
Problem #2:
The “Formal Description” was proposed by the Coordination Committee 11/03, the validation proposal accepted by the Standard Committee 11/17, and adopted by the validation WG 11/18. The argument against using “Precise Description” was that the “English Description” is also suppose to be precise.
Problem #3: related to issue 513
matthew
12/09/08 8:09 pm
In answer to Lyteck’s question on Problem #1 – The English description and the Precise description each need their own context. They need their own context because they’re expressed differently.
Problem #2 – take a look at Wikipedia for “formal”: http://en.wikipedia.org/wiki/Formal#Computer_science. Software and Models are precise but not formal, whereas Formal Methods are both formal and precise.
matthewdr
12/16/08 2:49 pm
Agreed at the VWG today:
* Change the format to give the guard on the context rather than the rule.
* Change the format so there is a separate guard and context for the English and XPath description.
Irina proposed naming the ‘formal’ rules as “XPath”. There was consensus. Lyteck will ask the standards committee to approve this name change.
lyteck
12/22/08 9:58 pm
Problem #1 (implementation):
Changed the XSLT so the current context ( tag) appears under both the English and Formal Descriptions. This is a first step toward implementation since we need to introduce new tagging to differentiate English and Formal Contexts.
The following is a proposed tagging which adds an element inside (becomes mixed content).
The advantage of this tagging is that if the element is not present (as it is not in 99% of the rules presently), then is used by default in the formal context. If is present, then its content is used for the formal context.
Example 1
Trade
———
current source XML: (one context applies to both descriptions)
“
…”
modified XML:
Trade//element(*, Trade)
“
…”
Example 2:
EquityOption
EquityDerivativeShortFormBase
———-
Current source XML:
“
…”
modified XML:
EquityOptionelement(*, EquityOption)
EquityDerivativeShortFormBaseelement(*, EquityDerivativeShortFormBase)
“
…”
You can generate the HTML to see how Eqd-2 and Eqd-26 appear.
In terms of timing, customized formal contexts may not make it in time for 4.5 recommendation. In which case, the context would be duplicated in both English and Formal Descriptions, which does not add much value (imho).(see shared-5, for an extreme example, where a rule has twenty-some contexts).
Do all Xpath contexts follow the format EquityOption <---> element(*, EquityOption)? If so, this could be easily automated in XSLT. If not, we need to populate the tags manually, to account for exceptions.
That said, couldn’t Problem #1 and Problem #3 simply be solved by adding wording in the Validation Architecture, or at the top of each Validation Rules page explaining the layout? i.e.,
1. Explaining that the context applies to both descriptions (even if only one contect appears once, at the top, below the rule ID)
2. Explaining that the guards apply to the context (even if the context is disconnected from a presentation perspective)
3. Explaining that “EquityOption (Complex type)” really means “element(*, EquityOption)” when applied to the formal description
would be simpler and would result in a more readable format (as was shown in the Readability Proposal and implemented prior to this issue 866, imho.
matthewdr
12/23/08 3:44 pm
The new layout looks good. The different contexts are now visible.
There is an indent before the Guard and before the Rule on the XPath version. Please remove that whitespace so it all lines up bette.
“Do all Xpath contexts follow the format EquityOption <---> element(*, EquityOption)?” – most do, but not all. There are a few exceptions.
We also agreed at the VWG to use the term “XPath” instead of “Formal Description”. This was Irina’s proposal that there was consensus upon. Please make this change to bring it into line with what was agreed.
matthewdr
02/03/09 2:24 pm
Discussed at the VWG again. Lyteck agreed to implement.
lyteck
02/03/09 7:46 pm
implemented as proposed:
– changed to XPath Description
– removed padding