Imported from previous forum
In various places, I see sample FIXML documents with no namespace definitions, eg:
<FIXML v=“4.4” …
Looking at FIXML 4.4 schema, I see
targetNamespace="http://www.fixprotocol.org/FIXML-4-4"
and in messages
<FIXML xmlns=“http://www.fixprotocol.org/FIXML-4-4” …
And for FIXML 5.0 SP2 schema, I see
targetNamespace="http://www.fixprotocol.org/FIXML-5-0-SP2"
and in messages
<FIXML xmlns=“http://www.fixprotocol.org/FIXML-5-0-SP2” v=“5.0” …
Q1. The examples without namespaces are wrong, right?
Or is this perhaps something older FIXML did?
Q2. Whats the rationale behind putting each service pack of FIXML 5.0 in a separate namespace?
It makes the v= redundant.
You can’t get to the v= without knowing the namespace the element is in, and if you know the namespace, you know the version (in more detail than just 5.0, I might add).
OK, so you can get to the v= positionally (the “v” attribute of the document root element), but using certain technologies (eg: XPath, its a little messier).
{{{ Andy
Most users of FIXML in the post trade space do not include the namespace in their messaging applications and do not do run time schema validation.
Regarding the namespace issue with specifying service packs and extension packs as part of the namespace. You are exactly correct - this becomes a maintenance nightmare. Our plans are to follow FpML’s lead and have the namespace specify a major version of FIXML (I don’t want to say “FIX” here because although highly correlated - versioning of the schema for FIXML is not fully linked to FIX versioning) and we would as you say use attributes on the FIXML field to indicate service pack and extension pack information. I would expect to see this about the time of SP3 release.
In various places, I see sample FIXML documents with no namespace definitions, eg:
<FIXML v=“4.4” …Looking at FIXML 4.4 schema, I see
targetNamespace=“http://www.fixprotocol.org/FIXML-4-4”
and in messages
<FIXML xmlns=“http://www.fixprotocol.org/FIXML-4-4” …And for FIXML 5.0 SP2 schema, I see
targetNamespace=“http://www.fixprotocol.org/FIXML-5-0-SP2”
and in messages
<FIXML xmlns=“http://www.fixprotocol.org/FIXML-5-0-SP2” v=“5.0” …Q1. The examples without namespaces are wrong, right?
Or is this perhaps something older FIXML did?Q2. Whats the rationale behind putting each service pack of FIXML 5.0 in a separate namespace?
It makes the v= redundant.
You can’t get to the v= without knowing the namespace the element is in, and if you know the namespace, you know the version (in more detail than just 5.0, I might add).
OK, so you can get to the v= positionally (the “v” attribute of the document root element), but using certain technologies (eg: XPath, its a little messier).{{{ Andy
So the root FIXML element namespace can be
A. nothing (eg: post trade scenarios you mention)
B. end in -M-N (eg: -4-4 for 4.4, or -5-0 for 5.0)
C. end in -M-N-SPS (eg: -5-0 for 5.0 SP2)
D. end in -M (eg: -5 for future intent, eg: 5.0 SP3 onwards)
and (excluding extension packs) the FIXML element can have
a. v="m.n"
b. v=“m.n” sp=“SPs”
So the algorithm for identifying the right set of schema to use is
Aa -> m-n (may require user config to supply SP value, as it can’t be inferred from the message)
Ab -> m-n-SPs
Ba -> if M-N == m-n then M-N else error
Bb -> error (this combo won’t happen)
Ca -> if M-N == m-n then M-N-SPS else error
Cb -> error (this combo won’t happen)
Da -> if M == m then m-n else error
Db -> if M == m then m-n-SPs else error
In addition, for case A, prior to schema validation, the FIXML xmlns= would need inserting.
Agreed?
{{{ Andy
I would either use eithe rno namespace as follows:
<?xml version="1.0" encoding="utf-8"?>Or add namespaces as follows:
<?xml version="1.0"?></AA:AllocInstrctn>
So the root FIXML element namespace can be
A. nothing (eg: post trade scenarios you mention)
B. end in -M-N (eg: -4-4 for 4.4, or -5-0 for 5.0)
C. end in -M-N-SPS (eg: -5-0 for 5.0 SP2)
D. end in -M (eg: -5 for future intent, eg: 5.0 SP3 onwards)and (excluding extension packs) the FIXML element can have
a. v=“m.n”
b. v=“m.n” sp=“SPs”So the algorithm for identifying the right set of schema to use is
Aa → m-n (may require user config to supply SP value, as it can’t be inferred from the message)
Ab → m-n-SPs
Ba → if M-N == m-n then M-N else error
Bb → error (this combo won’t happen)
Ca → if M-N == m-n then M-N-SPS else error
Cb → error (this combo won’t happen)
Da → if M == m then m-n else error
Db → if M == m then m-n-SPs else errorIn addition, for case A, prior to schema validation, the FIXML xmlns= would need inserting.
Agreed?
{{{ Andy
Yikes, a third possibility for the FIXML attributes
c. neither v= nor presumably sp= either
Resulting in
Ac -> the user must configure the major, minor and possibly the service pack
Bc -> M-N known, but may require user config to supply SP value)
Cc -> M-N-SPS
Dc -> M is known, but the user must configure the minor number and possibly the service pack)
Complicated.
{{{ Andy
Following the approach now taken by FpML I would propose the following:
http://www.fixprotocol.org/FIXML/4.4
And then implement a string that matched exactly with the format of the version string used with FIX, primarily in field BeginString(tag 8):
FIX.4.4
(of course the following are not valid in tag 8 any longer, but they are used within FIX).
FIX.5.0SP1
FIX.5.0SP2
FIX.5.0SP3
This would require a change.
Thinking out load - I wonder if we should simplify the FIXML Schema (many of the assumptions and requirements that led to the current structure are no longer valid) and have two sets of schemas for FIX.4.4 through FIX.5.0SP3, then deprecate the previous schemas?
A good topic for Repository Working Group and the GTC Governance Board.
What we have now is not sufficiently usable and is not really based upon best practices.