FpML Issues Tracker
closed
Minor
Always
Validation Rules
Admin
None
Summary
Section 4.6.1 states: "For the purposes of precision, extensibility, and robustness to change the structure of the Validation Rules is profiled. The rules of the profile are:
* The context for a validation rule must always be a type. ..."
This contradicts this context because the context is not a type:
Context: payerPartyReference shared-5 (Mandatory) If ../receiverPartyReference exists, then the @href attributes of the two elements must not be equal.
Notes:
andrew
04/15/08 12:00 pm
The bullet should have ‘or element’ appended to it.
Many of our rules are element based, and with the increasing usage of model groups within the schema to get around the limitations of inheritance, will probably become more so over time.
matthewdr
04/15/08 1:12 pm
The problem is that the definition is inside a group, and the group isn’t referenceable externally:
We don’t have access to groups externally, such as via XDM.
The only legal option today is to use the type containing the group.
Searching for: PayerReceiver.model
fpml-cd-4-4.xsd(629):
fpml-doc-4-4.xsd(496):
fpml-eqd-4-4.xsd(399):
fpml-eq-shared-4-4.xsd(349):
fpml-eq-shared-4-4.xsd(491):
fpml-eq-shared-4-4.xsd(966):
fpml-eq-shared-4-4.xsd(1162):
fpml-eq-shared-4-4.xsd(1252):
fpml-fx-4-4.xsd(521):
fpml-ird-4-4.xsd(918):
fpml-option-shared-4-4.xsd(272):
fpml-option-shared-4-4.xsd(497):
fpml-pretrade-4-4.xsd(47):
fpml-reconciliation-4-4.xsd(301):
fpml-reconciliation-4-4.xsd(358):
fpml-shared-4-4.xsd(1047):
fpml-shared-4-4.xsd(1077):
fpml-shared-4-4.xsd(1836):
fpml-shared-4-4.xsd(2427):
fpml-shared-4-4.xsd(2692):
Found 20 occurrence(s) in 10 file(s)
matthewdr
04/15/08 1:20 pm
Agreed that an element can be used for a context if there is no suitable type, because the context is a model group. If the context isn’t a model group, then an element cannot be used.
AJ will change the design guidelines to bar homonyms in elements.
matthewdr
04/29/08 1:55 pm
AJ pointed out that it is a homograph, not a homonym.
The document is “Modelling Guidelines”.
lyteck
12/11/08 8:02 pm
1. We could change wording of validation architecture section 4.7.1 to:
“The context for a validation rule must always be a type. However, an element can be used for a context if there is no suitable type, because the context is a model group. If the context isn’t a model group, then an element cannot be used.”
2. fix the context: remove (complex type) for payerPartyReference element
matthewdr
12/12/08 10:51 am
Agree with the intent of the proposal.
matthewdr
12/16/08 2:19 pm
Agreed at VWG today for Lyteck to implement as proposed, and add the bar on homographs to the Architecture document.
lyteck
12/16/08 8:46 pm
– implemented note 2217 as agreed.
– to do: update Architecture document.
lyteck
12/16/08 9:16 pm
the sentence was added to the FpML Architecture Specification 2.1, at the end of section 2.3.5:
“2.3.5 Elements
Elements define the vocabulary of tag names that can be used in an instance document to markup information. The XML schema language provides several ways in which elements may be used on their own or in conjunction with types to define a complex grammar.
The preferred style for FpML XML schema can be summarized as follows:
– All elements other than the document root element () MUST follow the lowerCamelCase naming convention as described for attributes.
– All elements MUST be associated with a globally defined type which defines their content (either a single value or a set of structured values).
– All elements other than the document root element () and those which are used to create substitution groups MUST be defined locally within a containing complex type or model group.
The names of elements SHOULD be carefully selected to indicate clearly the business meaning of the data value or data structure. As XML structures information hierarchically the name of a contained element SHOULD NOT be prefixed with all or part of its parent element’s name.
Additionally, homographs are barred in elements.”
matthewdr
12/17/08 9:30 am
Should really say “Each element name must be unique across elements with different meanings. Only elements with the same meaning may have the same name.”
Homographs are bad for element names, but quite legitimate for content in elements.