FpML Issues Tracker
closed
Block
Always
Architecture
SteveTurner
andrew
Summary
FpML 4.3 states it is backwards compatible with 4.2 (http://www.fpml.org/spec/2007/lcwd-fpml-4-3-2007-10-30/html/index.html with one proviso 1.6.2.1)
If this is true, one should be able to validate a 4.2 message using the 4.3 schema in any tool that supports validation against schema. However, this is not possible due to the namespace naming policy. http://www.fpml.org/spec/2007/tr-fpml-arch-2-1-2007-09-17/ - 4.4.1 That calls out using versioning (major & minor) as part of the namespace. This means that in FpML there can never be backwards compatibility as previous definitions exist only in a different namespace; not available from the new namespace - even for minor releases.
Notes:
h_mcallister
11/29/07 7:47 pm
Agreed: and if we were strict in this regard, the FpML namespace declaration would (still) be: xmlns:fpml=”http://www.fpml.org/2004/FpML-4″
h_mcallister
11/29/07 7:52 pm
Of course, that should read namespace *prefix* declaration …
targetNamespace=”http://www.fpml.org/2004/FpML-4″ xmlns:fpml=”http://www.fpml.org/2004/FpML-4″
xmlns=”http://www.fpml.org/2004/FpML-4″
mgratacos
11/29/07 10:55 pm
When you receive a message using this mechanism (no minor version in the namespace), how do you know the schema version that you should validate against?
Do you know it by looking at the version attribute?
h_mcallister
12/03/07 4:48 pm
Yes, the version attribute should be a reliable guide to the schema version for validation – but Steve’s point is that backward compatibility, as commonly understood, implies that it should be possible to validate any 4-x message (4-0, 4-1 etc.) against, say, the 4-4 schema – this is not possible because subsequent minor versions live in separate namespaces.
It’s (way) too late to look for a change of policy, at least in the 4-x series – but perhaps we should make it clear that minor versions exhibit only “structural” backward compatibility, but are not formally compatible.
SteveTurner
12/04/07 1:39 pm
mgratacos
12/13/07 3:07 pm
AWG 2007-12-13:
Agreed it’s a good idea.
It requires to be strict on backward compatibility between minor versions (as we should be)
It is probably too late to do this in 4.x but we should seriously consider it in the next draft for 5.
We need a better set of test cases to check backward compatibility.
Further discussion next week.
mgratacos
02/29/08 4:11 pm
I attached the paper produced by Andrew Jacobs.
apparry
05/22/08 8:33 am
We have previously discussed the problem of circular definitions when using a single namespace for every version of the 5-X series, whereby version attribute, expectedBuild attribute, … are defined in some 5-X schema version, but which one ? ( ie )
Instance Document A, namespace “v5”, version attribute “5-2”
Consider attribute group “VersionAttributues.atts”
Mandatory version attribute will have schema legal value “5-2” in schema version 5-2, 5-3, 5-4, … 5-X so which one should the processor use ? Namespace “v5” would be the same for the entire “5-X” series
expectedBuild and actualBuild are optional attributes
Suppose the instance document does populate expectedBuild with the value “8050”
Does this mean that the processor of this document should validate using build “8050” ? This would mean you now are using a unique schema version per document. If this is not the case, how should the correct schema version be determined ?
andrew
05/22/08 10:53 am
A processing application is normally built to a specific version of the FpML grammar. When it receives a document it should validate it against its known schema, say ns=v5-Confirmation, version=5-1, build 8050. The result of the parsing depends on the content of the document and the way that the version attribute is defined:
If the document references any view other than v5-confirmation the XML parse will fail.
If the version attribute is defined as an enumeration (as in current FpML) then the XML parser will only recognise backwards compatible schemas (5-0 & 5-1) – a later version number will generate a parser failure. As the application was designed with knowledge of the 5-1 and 5-0 schemas it should be able to process the message contents.
If the version attribute is defined as a pattern (e.g. accepts 5-*) then the XML parser will accept any 5-0 or 5-1 document as these should be completely compatible with the schema grammar and additionally it will accept any 5-2 or later document provided it only contains features present in the 5-1 schema (i.e. nothing added after 5-1).
In either case if the XML parse is successful the application can examine the build attributes in the resulting DOM tree to determine the exact schema versions used by the sender and itself if they are provided and the processing is build sensitive.
mgratacos
03/19/09 2:21 pm
The Standards Committee agreed to implement AWG’s proposal to change the namespace URI in version 5.0 (see attached paper).
mgratacos
03/19/09 2:22 pm
Pending implementation.
mgratacos
03/25/09 5:05 pm
This has been committed to the 5.0 branch (scriptsadd-version.xsl).