Imported from previous forum
I’m working to understand the patterns in the FIXML Schema. Obviously when you’re looking at something new, questions arise. The purpose of the question here is not so much about the subject in the question, but more so to better understand the patterns of the schema and anomolies noticed in the discovery process. Having these sorts of questions answered helps users to better understand the schema’s logic and design patterns as the user is in the discovery process.
With that said, here’s the questions:
Why is the "MsgSeqNum’ type here in:
fixml-components-base-4-4.xsd
<!-- Message Header -->
…
<!-- <xs:attribute name=“MsgSeqNum” type=“xs:int” use=“optional”/> -->
not typecast as type="MsgSeqNum_t" as declared here in: fixml-shared-base-4-4.xsd
…
<!-- <xs:simpleType name="MsgSeqNum_t"> -->
Most of the attributes within the attribute groups defined in the ‘shared-base’ are typecast to types already defined and ending with an '_t" so why not this one?
Thanks, John M
A little more to my question:
> I’m working to understand the patterns in the FIXML Schema. Obviously when you’re looking at something new, questions arise. The purpose of the question here is not so much about the subject in the question, but more so to better understand the patterns of the schema and anomolies noticed in the discovery process. Having these sorts of questions answered helps users to better understand the schema’s logic and design patterns as the user is in the discovery process.
>
> With that said, here’s the questions:
>
> Why is the “MsgSeqNum’ type here in:
> fixml-components-base-4-4.xsd
> <!-- Message Header -->
> …
> <!-- <xs:attribute name=“MsgSeqNum” type=“xs:int” use=“optional”/> -->
>
> not typecast as type=“MsgSeqNum_t” as declared here in: fixml-shared-base-4-4.xsd
> …
> <!-- <xs:simpleType name=“MsgSeqNum_t”> -->
>
>
> Most of the attributes within the attribute groups defined in the ‘shared-base’ are typecast to types already defined and ending with an '_t” so why not this one?
Does it something to do with the fact that ultimately “MsgSeqNum_t” is typecast to “SeqNum” which itself is typecast to “positiveInteger” and “MsgSeqNum” is typecast to just an integer? If so, what’s the reasoning behind this?
>
> Thanks, John M
>
Thanks again, John M
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
John,
You have identified an error in the draft schema.
We are not fully generating the this part of the schema with our repository toolset.
The implementation should be consistent with the design patterns we have started to document in the FIXML Schema Guide - available as part of draft#1.
SeqNum should be the attribute in the message header that is based upon the MsgSeqNum_t simple type defined in the fixml-shared-base file.
Jim
> A little more to my question:
>
> > I’m working to understand the patterns in the FIXML Schema. Obviously when you’re looking at something new, questions arise. The purpose of the question here is not so much about the subject in the question, but more so to better understand the patterns of the schema and anomolies noticed in the discovery process. Having these sorts of questions answered helps users to better understand the schema’s logic and design patterns as the user is in the discovery process.
> >
> > With that said, here’s the questions:
> >
> > Why is the “MsgSeqNum’ type here in:
> > fixml-components-base-4-4.xsd
> > <!-- Message Header -->
> > …
> > <!-- <xs:attribute name=“MsgSeqNum” type=“xs:int” use=“optional”/> -->
> >
> > not typecast as type=“MsgSeqNum_t” as declared here in: fixml-shared-base-4-4.xsd
> > …
> > <!-- <xs:simpleType name=“MsgSeqNum_t”> -->
> >
> >
> > Most of the attributes within the attribute groups defined in the ‘shared-base’ are typecast to types already defined and ending with an '_t” so why not this one?
>
> Does it something to do with the fact that ultimately “MsgSeqNum_t” is typecast to “SeqNum” which itself is typecast to “positiveInteger” and “MsgSeqNum” is typecast to just an integer? If so, what’s the reasoning behind this?
>
> >
> > Thanks, John M
> >
>
> Thanks again, John M
>