Optional and Custom Elements minOccurs set to 0?

gerrycapone_x · November 24, 2003, 7:10pm

Imported from previous forum

gerrycapone_x · November 24, 2003, 7:10pm

Should the minOccurs attribute be set to zero for all optional and custom children?

Again my motivation here is becuase of what happens after FIXXML is run through a code generator (castor). Currently I have to create an empty NewOrderSingleELementsOptional object and assign it to the NewOrderSingle for the castor to properly marshall the Java representation of a NewOrderSingle back out to FIXML.

Below is some sample code:

NewOrdSingle ord = new NewOrdSingle();
…
NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
ord.setNewOrderSingleElementsOptional( noseo);

I have to create an empty object even though I am not setting any optional elements.

Not a huge issue until you start worrying about how fast I can process and route thousands of orders and executions.

Gerry Capone

fplpo_x · November 24, 2003, 7:34pm

[ original email was from Jim Northey - jnorthey@lasalletech.com ]
You are saying set the minOccurs for the group - I think we should do this. Glad your running ahead of us a bit. Will try and get this into final draft.

> Should the minOccurs attribute be set to zero for all optional and custom children?
>
> Again my motivation here is becuase of what happens after FIXXML is run through a code generator (castor). Currently I have to create an empty NewOrderSingleELementsOptional object and assign it to the NewOrderSingle for the castor to properly marshall the Java representation of a NewOrderSingle back out to FIXML.
>
> Below is some sample code:
> -----------
> NewOrdSingle ord = new NewOrdSingle();
> …
> NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
> ord.setNewOrderSingleElementsOptional( noseo);
> ------------
> I have to create an empty object even though I am not setting any optional elements.
>
> Not a huge issue until you start worrying about how fast I can process and route thousands of orders and executions.
>
> Gerry Capone
>

sikngai_x · November 24, 2003, 10:59pm

Gentlemen,

I dont think setting minOccurs for xxxElementsOptional and xxxElementsCustom is the correct way of handling the limitation of Castor. First of all, the xs:group construct is a logical construct in XML schema definition to provide better structure and readability. The xxxElementsRequired/Optional/Custom tags do NOT show up in the actual conforming XML documents (whether you set its minOccurs to 0 or not).

Even if you set minOccurs to 0. It is still NOT satisfactory. You will still be accessing something like a symbol by (forgive me of any misspelling):
ioi.getIOIElementsRequired().getInstrmt().getSym();

instead of:
ioi.getInstrmt().getSym();

The getIOIElementsRequired layer is way too articial to show up in the code. Of course, it also costs more pain to code and time to run because of these useless objects.

By the way, if you are to set minOccurs to 0 for xxxElementsOptional and xxxElementsCustom. You HAVE TO do the same to xxxElementsRequired! (to cover cases whereby you have NO mandatory elements).

My position is that the current FIXML schema is nice and structured. There is a reason why the design team chose to use xs:group. I dont think it is advisable to twist and turn the schema at this point because of some short comings of third party tools (this can be a never-ending nightmare).

I am using Castor against the FIXML schema too. To me, this is a problem of Castor (or more accurately, users of Castor 8-( ), not FIXML. By the way, I see a few other problems as well (Gerry, in my last email to you, I already mentioned that other than the "redefine" vs "include" issue, you will encounter this Element groups problem). What I had done was to create a suite of scripts to transform the FIXML schema, bypassing the Castor shortcomings and inserting our own custom tags. With it, it costs me very little time to upgrade to new revisions of the schema.

Sik Ngai
Alberta Market Solutions Ltd.
M: +1-403-714-2288
F: +1-403-685-4025
P: +1-403-246-5104
E: sik.ngai@albertasolutions.com

> You are saying set the minOccurs for the group - I think we should do this. Glad your running ahead of us a bit. Will try and get this into final draft.
>
> > Should the minOccurs attribute be set to zero for all optional and custom children?
> >
> > Again my motivation here is becuase of what happens after FIXXML is run through a code generator (castor). Currently I have to create an empty NewOrderSingleELementsOptional object and assign it to the NewOrderSingle for the castor to properly marshall the Java representation of a NewOrderSingle back out to FIXML.
> >
> > Below is some sample code:
> > -----------
> > NewOrdSingle ord = new NewOrdSingle();
> > …
> > NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
> > ord.setNewOrderSingleElementsOptional( noseo);
> > ------------
> > I have to create an empty object even though I am not setting any optional elements.
> >
> > Not a huge issue until you start worrying about how fast I can process and route thousands of orders and executions.
> >
> > Gerry Capone
> >
>

gerrycapone_x · November 25, 2003, 7:24pm

Hi Sik,
Take Castor out the equation for a moment. I think the question is fundamental.
If a structure is labeled "optional" or "custom"( custom to me implies it is optional), then
it seems logical that "minOccurs" should be set to zero. If the attribute minOccurs is not set, then the default is 1.

From the W3C Schema Primer: "an element is REQUIRED to appear when the value of minOccurs is 1 or more."

> Gentlemen,
>
> I dont think setting minOccurs for xxxElementsOptional and xxxElementsCustom is the correct way of handling the limitation of Castor. First of all, the xs:group construct is a logical construct in XML schema definition to provide better structure and readability. The xxxElementsRequired/Optional/Custom tags do NOT show up in the actual conforming XML documents (whether you set its minOccurs to 0 or not).
>
> Even if you set minOccurs to 0. It is still NOT satisfactory. You will still be accessing something like a symbol by (forgive me of any misspelling):
> ioi.getIOIElementsRequired().getInstrmt().getSym();
>
> instead of:
> ioi.getInstrmt().getSym();
>
> The getIOIElementsRequired layer is way too articial to show up in the code. Of course, it also costs more pain to code and time to run because of these useless objects.
>
> By the way, if you are to set minOccurs to 0 for xxxElementsOptional and xxxElementsCustom. You HAVE TO do the same to xxxElementsRequired! (to cover cases whereby you have NO mandatory elements).
>
> My position is that the current FIXML schema is nice and structured. There is a reason why the design team chose to use xs:group. I dont think it is advisable to twist and turn the schema at this point because of some short comings of third party tools (this can be a never-ending nightmare).
>
> I am using Castor against the FIXML schema too. To me, this is a problem of Castor (or more accurately, users of Castor 8-( ), not FIXML. By the way, I see a few other problems as well (Gerry, in my last email to you, I already mentioned that other than the "redefine" vs "include" issue, you will encounter this Element groups problem). What I had done was to create a suite of scripts to transform the FIXML schema, bypassing the Castor shortcomings and inserting our own custom tags. With it, it costs me very little time to upgrade to new revisions of the schema.
>
> Sik Ngai
> Alberta Market Solutions Ltd.
> M: +1-403-714-2288
> F: +1-403-685-4025
> P: +1-403-246-5104
> E: sik.ngai@albertasolutions.com
>
> > You are saying set the minOccurs for the group - I think we should do this. Glad your running ahead of us a bit. Will try and get this into final draft.
> >
> > > Should the minOccurs attribute be set to zero for all optional and custom children?
> > >
> > > Again my motivation here is becuase of what happens after FIXXML is run through a code generator (castor). Currently I have to create an empty NewOrderSingleELementsOptional object and assign it to the NewOrderSingle for the castor to properly marshall the Java representation of a NewOrderSingle back out to FIXML.
> > >
> > > Below is some sample code:
> > > -----------
> > > NewOrdSingle ord = new NewOrdSingle();
> > > …
> > > NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
> > > ord.setNewOrderSingleElementsOptional( noseo);
> > > ------------
> > > I have to create an empty object even though I am not setting any optional elements.
> > >
> > > Not a huge issue until you start worrying about how fast I can process and route thousands of orders and executions.
> > >
> > > Gerry Capone
> > >
> >
>

sikngai_x · November 26, 2003, 12:25am

Gerry,

If you put a minOccurs=0 at the <xs:group ref…> level, it means the WHOLE GROUP IS OPTIONAL, INSTEAD OF THE INDIVIDUAL SUBELEMENTS - which I dont think is what you want! Using the following as an example,

&lt;xs:group name=&quot;BaseHeaderElementsOptional&quot;&gt;
	&lt;xs:sequence&gt;
		&lt;xs:element name=&quot;OnBhlfOf&quot; type=&quot;OnBehalfOf_t&quot; minOccurs=&quot;0&quot;/&gt;
		&lt;xs:element name=&quot;DlvrTo&quot; type=&quot;DeliverTo_t&quot; minOccurs=&quot;0&quot;/&gt;
		&lt;xs:element name=&quot;Hop&quot; type=&quot;Hop_t&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/&gt;
	&lt;/xs:sequence&gt;
&lt;/xs:group&gt;

"OnBhlfOf", "DlvrTo", and "Hop" should be allowed to be present or not independent of each other (this is achieved by having minOccurs=0 at their level).
Assuming we remove minOccurs=0 from the three sub-elements and instead add it where you reference the group
"BaseHeaderElementsOptional", it means that either all 3 must be defined or none of the 3 can be defined. It is wrong!

I think the confusion is resulted from what you saw got generated by castor. As I said, the groups are artifacts to aid readability and re-use. They are there to be substituted. They do NOT exist as constructs in the conforming XML documents!

E.g. the following is a well-formed IOI message:

<?xml version="1.0" encoding="UTF-8"?>
<FIXML xmlns="http://www.fixprotocol.org/FIXML-4-4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.fixprotocol.org/FIXML-4-4
F:\fix44\origschema\fixml-main-4-4.xsd">
<IOI ID="ioiid" TransTyp="N" Side="1" Qty="1000">
<Hdr>
<Sndr ID="sender"/>
<Tgt ID="target" Sub="subid"/>
<OnBhlfOf ID="orig" Sub="orig_sub"/>
</Hdr>
<Instrmt Sym="ABC"/>
</IOI>
</FIXML>

Take a close look at the "Hdr" block. You dont see something that reads "BaseHeaderElementsOptional" in the conforming XML document.

Adding minOccurs=0 to the references of the groups OR removing the ElementsRequired/Optional/Custom constructs altogether are NOT going to change what the conforming XML documents will look like.

However adding minOccurs=0 to the group references, while does not hurt in a tangible way, is superfluous and, in my personal point of view, is incorrect semantically (when you put a minOccurs=0 at the group ref level, you somehow imply the occurrence of ALL sub-elements in the group to be interrelated - i.e. they should all be there or all not be there)

As to removing the groups, Jim had already stated in his email re. the flattening issue of the reason of using the groups (which I agreed to).

I hope I understood what you said and my points in this email are clear and address the issue at hand 8-).

Bottomline, I think the current schema is good as is (w.r.t. our current thread of discussion and the flattening of header issue).

Sik.

Alberta Market Solutions Ltd.
M: +1-403-714-2288
F: +1-403-685-4025
P: +1-403-246-5104
E: sik.ngai@albertasolutions.com

> Hi Sik,
> Take Castor out the equation for a moment. I think the question is fundamental.
> If a structure is labeled "optional" or "custom"( custom to me implies it is optional), then
> it seems logical that "minOccurs" should be set to zero. If the attribute minOccurs is not set, then the default is 1.
>
> From the W3C Schema Primer: "an element is REQUIRED to appear when the value of minOccurs is 1 or more."
>
> > Gentlemen,
> >
> > I dont think setting minOccurs for xxxElementsOptional and xxxElementsCustom is the correct way of handling the limitation of Castor. First of all, the xs:group construct is a logical construct in XML schema definition to provide better structure and readability. The xxxElementsRequired/Optional/Custom tags do NOT show up in the actual conforming XML documents (whether you set its minOccurs to 0 or not).
> >
> > Even if you set minOccurs to 0. It is still NOT satisfactory. You will still be accessing something like a symbol by (forgive me of any misspelling):
> > ioi.getIOIElementsRequired().getInstrmt().getSym();
> >
> > instead of:
> > ioi.getInstrmt().getSym();
> >
> > The getIOIElementsRequired layer is way too articial to show up in the code. Of course, it also costs more pain to code and time to run because of these useless objects.
> >
> > By the way, if you are to set minOccurs to 0 for xxxElementsOptional and xxxElementsCustom. You HAVE TO do the same to xxxElementsRequired! (to cover cases whereby you have NO mandatory elements).
> >
> > My position is that the current FIXML schema is nice and structured. There is a reason why the design team chose to use xs:group. I dont think it is advisable to twist and turn the schema at this point because of some short comings of third party tools (this can be a never-ending nightmare).
> >
> > I am using Castor against the FIXML schema too. To me, this is a problem of Castor (or more accurately, users of Castor 8-( ), not FIXML. By the way, I see a few other problems as well (Gerry, in my last email to you, I already mentioned that other than the "redefine" vs "include" issue, you will encounter this Element groups problem). What I had done was to create a suite of scripts to transform the FIXML schema, bypassing the Castor shortcomings and inserting our own custom tags. With it, it costs me very little time to upgrade to new revisions of the schema.
> >
> > Sik Ngai
> > Alberta Market Solutions Ltd.
> > M: +1-403-714-2288
> > F: +1-403-685-4025
> > P: +1-403-246-5104
> > E: sik.ngai@albertasolutions.com
> >
> > > You are saying set the minOccurs for the group - I think we should do this. Glad your running ahead of us a bit. Will try and get this into final draft.
> > >
> > > > Should the minOccurs attribute be set to zero for all optional and custom children?
> > > >
> > > > Again my motivation here is becuase of what happens after FIXXML is run through a code generator (castor). Currently I have to create an empty NewOrderSingleELementsOptional object and assign it to the NewOrderSingle for the castor to properly marshall the Java representation of a NewOrderSingle back out to FIXML.
> > > >
> > > > Below is some sample code:
> > > > -----------
> > > > NewOrdSingle ord = new NewOrdSingle();
> > > > …
> > > > NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
> > > > ord.setNewOrderSingleElementsOptional( noseo);
> > > > ------------
> > > > I have to create an empty object even though I am not setting any optional elements.
> > > >
> > > > Not a huge issue until you start worrying about how fast I can process and route thousands of orders and executions.
> > > >
> > > > Gerry Capone
> > > >
> > >
> >
>

gerrycapone_x · November 26, 2003, 6:49pm

Sik,

What do you think about just adding the "minOccurs=0" when referring to the group?
This would be in the declaration of the "group ref=xxxElementsOptional" (and "ref=xxxElementsCustom") for the xxx_message_t types?

An example of this is in NewOrderSingle_message_t, where you see
<xs:sequence>
<xs:group ref="NewOrderSingleElementsRequired" />
<xs:group ref="NewOrderSingleElementsOptional" />
<xs:group ref="NewOrderSingleElementsCustom" />
</xs:sequence>

Adding minOccurs=0 gives us
<xs:sequence>
<xs:group ref="NewOrderSingleElementsRequired" />
<xs:group ref="NewOrderSingleElementsOptional" minOccurs="0" />
<xs:group ref="NewOrderSingleElementsCustom" minOccurs="0" />
</xs:sequence>

I do agree that adding minOccurs to the group definitions is not the way to go.

Consider adding minOccurs=0 to group references (as illustrated above). This seems harmless, logical, and as a bonus gives us a work-around for a bug in Castor that helps overall performance a bit.(BTW, the Castor bug is 1440 "incorrect group validation for optional components")
Here is the URL:
http://bugzilla.exolab.org/show_bug.cgi?id=1440

> Gerry,
>
> If you put a minOccurs=0 at the <xs:group ref…> level, it means the WHOLE GROUP IS OPTIONAL, INSTEAD OF THE INDIVIDUAL SUBELEMENTS - which I dont think is what you want! Using the following as an example,
>
> <xs:group name="BaseHeaderElementsOptional">
> <xs:sequence>
> <xs:element name="OnBhlfOf" type="OnBehalfOf_t" minOccurs="0"/>
> <xs:element name="DlvrTo" type="DeliverTo_t" minOccurs="0"/>
> <xs:element name="Hop" type="Hop_t" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:group>
>
> "OnBhlfOf", "DlvrTo", and "Hop" should be allowed to be present or not independent of each other (this is achieved by having minOccurs=0 at their level).
> Assuming we remove minOccurs=0 from the three sub-elements and instead add it where you reference the group
> "BaseHeaderElementsOptional", it means that either all 3 must be defined or none of the 3 can be defined. It is wrong!
>
> I think the confusion is resulted from what you saw got generated by castor. As I said, the groups are artifacts to aid readability and re-use. They are there to be substituted. They do NOT exist as constructs in the conforming XML documents!
>
> E.g. the following is a well-formed IOI message:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <FIXML xmlns="http://www.fixprotocol.org/FIXML-4-4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.fixprotocol.org/FIXML-4-4
> F:\fix44\origschema\fixml-main-4-4.xsd">
> <IOI ID="ioiid" TransTyp="N" Side="1" Qty="1000">
> <Hdr>
> <Sndr ID="sender"/>
> <Tgt ID="target" Sub="subid"/>
> <OnBhlfOf ID="orig" Sub="orig_sub"/>
> </Hdr>
> <Instrmt Sym="ABC"/>
> </IOI>
> </FIXML>
>
> Take a close look at the "Hdr" block. You dont see something that reads "BaseHeaderElementsOptional" in the conforming XML document.
>
> Adding minOccurs=0 to the references of the groups OR removing the ElementsRequired/Optional/Custom constructs altogether are NOT going to change what the conforming XML documents will look like.
>
> However adding minOccurs=0 to the group references, while does not hurt in a tangible way, is superfluous and, in my personal point of view, is incorrect semantically (when you put a minOccurs=0 at the group ref level, you somehow imply the occurrence of ALL sub-elements in the group to be interrelated - i.e. they should all be there or all not be there)
>
> As to removing the groups, Jim had already stated in his email re. the flattening issue of the reason of using the groups (which I agreed to).
>
> I hope I understood what you said and my points in this email are clear and address the issue at hand 8-).
>
> Bottomline, I think the current schema is good as is (w.r.t. our current thread of discussion and the flattening of header issue).
>
> Sik.
>
> Alberta Market Solutions Ltd.
> M: +1-403-714-2288
> F: +1-403-685-4025
> P: +1-403-246-5104
> E: sik.ngai@albertasolutions.com
>
>
> > Hi Sik,
> > Take Castor out the equation for a moment. I think the question is fundamental.
> > If a structure is labeled "optional" or "custom"( custom to me implies it is optional), then
> > it seems logical that "minOccurs" should be set to zero. If the attribute minOccurs is not set, then the default is 1.
> >
> > From the W3C Schema Primer: "an element is REQUIRED to appear when the value of minOccurs is 1 or more."
> >
> > > Gentlemen,
> > >
> > > I dont think setting minOccurs for xxxElementsOptional and xxxElementsCustom is the correct way of handling the limitation of Castor. First of all, the xs:group construct is a logical construct in XML schema definition to provide better structure and readability. The xxxElementsRequired/Optional/Custom tags do NOT show up in the actual conforming XML documents (whether you set its minOccurs to 0 or not).
> > >
> > > Even if you set minOccurs to 0. It is still NOT satisfactory. You will still be accessing something like a symbol by (forgive me of any misspelling):
> > > ioi.getIOIElementsRequired().getInstrmt().getSym();
> > >
> > > instead of:
> > > ioi.getInstrmt().getSym();
> > >
> > > The getIOIElementsRequired layer is way too articial to show up in the code. Of course, it also costs more pain to code and time to run because of these useless objects.
> > >
> > > By the way, if you are to set minOccurs to 0 for xxxElementsOptional and xxxElementsCustom. You HAVE TO do the same to xxxElementsRequired! (to cover cases whereby you have NO mandatory elements).
> > >
> > > My position is that the current FIXML schema is nice and structured. There is a reason why the design team chose to use xs:group. I dont think it is advisable to twist and turn the schema at this point because of some short comings of third party tools (this can be a never-ending nightmare).
> > >
> > > I am using Castor against the FIXML schema too. To me, this is a problem of Castor (or more accurately, users of Castor 8-( ), not FIXML. By the way, I see a few other problems as well (Gerry, in my last email to you, I already mentioned that other than the "redefine" vs "include" issue, you will encounter this Element groups problem). What I had done was to create a suite of scripts to transform the FIXML schema, bypassing the Castor shortcomings and inserting our own custom tags. With it, it costs me very little time to upgrade to new revisions of the schema.
> > >
> > > Sik Ngai
> > > Alberta Market Solutions Ltd.
> > > M: +1-403-714-2288
> > > F: +1-403-685-4025
> > > P: +1-403-246-5104
> > > E: sik.ngai@albertasolutions.com
> > >
> > > > You are saying set the minOccurs for the group - I think we should do this. Glad your running ahead of us a bit. Will try and get this into final draft.
> > > >
> > > > > Should the minOccurs attribute be set to zero for all optional and custom children?
> > > > >
> > > > > Again my motivation here is becuase of what happens after FIXXML is run through a code generator (castor). Currently I have to create an empty NewOrderSingleELementsOptional object and assign it to the NewOrderSingle for the castor to properly marshall the Java representation of a NewOrderSingle back out to FIXML.
> > > > >
> > > > > Below is some sample code:
> > > > > -----------
> > > > > NewOrdSingle ord = new NewOrdSingle();
> > > > > …
> > > > > NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
> > > > > ord.setNewOrderSingleElementsOptional( noseo);
> > > > > ------------
> > > > > I have to create an empty object even though I am not setting any optional elements.
> > > > >
> > > > > Not a huge issue until you start worrying about how fast I can process and route thousands of orders and executions.
> > > > >
> > > > > Gerry Capone
> > > > >
> > > >
> > >
> >
>

sikngai_x · November 26, 2003, 9:48pm

Gerry,

I guess I didnt make myself clear. Firstly, minOccurs is NOT available in group definitions. It is only available in group references. As such, when I said minOccurs=0 was not advisable, I meant they should not be used in group references (which was what you were proposing in your latest response).

I encountered the castor bug (1440) as well BEFORE when I first tried out the new schema. I maintain that the solution should not be by adding minOccurs=0 to the group references, BUT by preprocessing the FIXML schema and eliminating all element groups before castor code generation.

If you like, give me a call.

Sik.
Alberta Market Solutions Ltd.
M: +1-403-714-2288
F: +1-403-685-4025
P: +1-403-246-5104
E: sik.ngai@albertasolutions.com

P.S. if you choose to work around the castor problem by introducing minOccurs=0, you have to check all ElementRequired groups as well. For whichever ElementRequired whose definition is a empty set, make sure you add minOccurs=0 to its reference or you will encounter the same castor problem.

> Sik,
>
> What do you think about just adding the "minOccurs=0" when referring to the group?
> This would be in the declaration of the "group ref=xxxElementsOptional" (and "ref=xxxElementsCustom") for the xxx_message_t types?
>
> An example of this is in NewOrderSingle_message_t, where you see
> <xs:sequence>
> <xs:group ref="NewOrderSingleElementsRequired" />
> <xs:group ref="NewOrderSingleElementsOptional" />
> <xs:group ref="NewOrderSingleElementsCustom" />
> </xs:sequence>
>
> Adding minOccurs=0 gives us
> <xs:sequence>
> <xs:group ref="NewOrderSingleElementsRequired" />
> <xs:group ref="NewOrderSingleElementsOptional" minOccurs="0" />
> <xs:group ref="NewOrderSingleElementsCustom" minOccurs="0" />
> </xs:sequence>
>
>
> I do agree that adding minOccurs to the group definitions is not the way to go.
>
> Consider adding minOccurs=0 to group references (as illustrated above). This seems harmless, logical, and as a bonus gives us a work-around for a bug in Castor that helps overall performance a bit.(BTW, the Castor bug is 1440 "incorrect group validation for optional components")
> Here is the URL:
> http://bugzilla.exolab.org/show_bug.cgi?id=1440
>
>
>
>
>
> > Gerry,
> >
> > If you put a minOccurs=0 at the <xs:group ref…> level, it means the WHOLE GROUP IS OPTIONAL, INSTEAD OF THE INDIVIDUAL SUBELEMENTS - which I dont think is what you want! Using the following as an example,
> >
> > <xs:group name="BaseHeaderElementsOptional">
> > <xs:sequence>
> > <xs:element name="OnBhlfOf" type="OnBehalfOf_t" minOccurs="0"/>
> > <xs:element name="DlvrTo" type="DeliverTo_t" minOccurs="0"/>
> > <xs:element name="Hop" type="Hop_t" minOccurs="0" maxOccurs="unbounded"/>
> > </xs:sequence>
> > </xs:group>
> >
> > "OnBhlfOf", "DlvrTo", and "Hop" should be allowed to be present or not independent of each other (this is achieved by having minOccurs=0 at their level).
> > Assuming we remove minOccurs=0 from the three sub-elements and instead add it where you reference the group
> > "BaseHeaderElementsOptional", it means that either all 3 must be defined or none of the 3 can be defined. It is wrong!
> >
> > I think the confusion is resulted from what you saw got generated by castor. As I said, the groups are artifacts to aid readability and re-use. They are there to be substituted. They do NOT exist as constructs in the conforming XML documents!
> >
> > E.g. the following is a well-formed IOI message:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <FIXML xmlns="http://www.fixprotocol.org/FIXML-4-4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.fixprotocol.org/FIXML-4-4
> > F:\fix44\origschema\fixml-main-4-4.xsd">
> > <IOI ID="ioiid" TransTyp="N" Side="1" Qty="1000">
> > <Hdr>
> > <Sndr ID="sender"/>
> > <Tgt ID="target" Sub="subid"/>
> > <OnBhlfOf ID="orig" Sub="orig_sub"/>
> > </Hdr>
> > <Instrmt Sym="ABC"/>
> > </IOI>
> > </FIXML>
> >
> > Take a close look at the "Hdr" block. You dont see something that reads "BaseHeaderElementsOptional" in the conforming XML document.
> >
> > Adding minOccurs=0 to the references of the groups OR removing the ElementsRequired/Optional/Custom constructs altogether are NOT going to change what the conforming XML documents will look like.
> >
> > However adding minOccurs=0 to the group references, while does not hurt in a tangible way, is superfluous and, in my personal point of view, is incorrect semantically (when you put a minOccurs=0 at the group ref level, you somehow imply the occurrence of ALL sub-elements in the group to be interrelated - i.e. they should all be there or all not be there)
> >
> > As to removing the groups, Jim had already stated in his email re. the flattening issue of the reason of using the groups (which I agreed to).
> >
> > I hope I understood what you said and my points in this email are clear and address the issue at hand 8-).
> >
> > Bottomline, I think the current schema is good as is (w.r.t. our current thread of discussion and the flattening of header issue).
> >
> > Sik.
> >
> > Alberta Market Solutions Ltd.
> > M: +1-403-714-2288
> > F: +1-403-685-4025
> > P: +1-403-246-5104
> > E: sik.ngai@albertasolutions.com
> >
> >
> > > Hi Sik,
> > > Take Castor out the equation for a moment. I think the question is fundamental.
> > > If a structure is labeled "optional" or "custom"( custom to me implies it is optional), then
> > > it seems logical that "minOccurs" should be set to zero. If the attribute minOccurs is not set, then the default is 1.
> > >
> > > From the W3C Schema Primer: "an element is REQUIRED to appear when the value of minOccurs is 1 or more."
> > >
> > > > Gentlemen,
> > > >
> > > > I dont think setting minOccurs for xxxElementsOptional and xxxElementsCustom is the correct way of handling the limitation of Castor. First of all, the xs:group construct is a logical construct in XML schema definition to provide better structure and readability. The xxxElementsRequired/Optional/Custom tags do NOT show up in the actual conforming XML documents (whether you set its minOccurs to 0 or not).
> > > >
> > > > Even if you set minOccurs to 0. It is still NOT satisfactory. You will still be accessing something like a symbol by (forgive me of any misspelling):
> > > > ioi.getIOIElementsRequired().getInstrmt().getSym();
> > > >
> > > > instead of:
> > > > ioi.getInstrmt().getSym();
> > > >
> > > > The getIOIElementsRequired layer is way too articial to show up in the code. Of course, it also costs more pain to code and time to run because of these useless objects.
> > > >
> > > > By the way, if you are to set minOccurs to 0 for xxxElementsOptional and xxxElementsCustom. You HAVE TO do the same to xxxElementsRequired! (to cover cases whereby you have NO mandatory elements).
> > > >
> > > > My position is that the current FIXML schema is nice and structured. There is a reason why the design team chose to use xs:group. I dont think it is advisable to twist and turn the schema at this point because of some short comings of third party tools (this can be a never-ending nightmare).
> > > >
> > > > I am using Castor against the FIXML schema too. To me, this is a problem of Castor (or more accurately, users of Castor 8-( ), not FIXML. By the way, I see a few other problems as well (Gerry, in my last email to you, I already mentioned that other than the "redefine" vs "include" issue, you will encounter this Element groups problem). What I had done was to create a suite of scripts to transform the FIXML schema, bypassing the Castor shortcomings and inserting our own custom tags. With it, it costs me very little time to upgrade to new revisions of the schema.
> > > >
> > > > Sik Ngai
> > > > Alberta Market Solutions Ltd.
> > > > M: +1-403-714-2288
> > > > F: +1-403-685-4025
> > > > P: +1-403-246-5104
> > > > E: sik.ngai@albertasolutions.com
> > > >
> > > > > You are saying set the minOccurs for the group - I think we should do this. Glad your running ahead of us a bit. Will try and get this into final draft.
> > > > >
> > > > > > Should the minOccurs attribute be set to zero for all optional and custom children?
> > > > > >
> > > > > > Again my motivation here is becuase of what happens after FIXXML is run through a code generator (castor). Currently I have to create an empty NewOrderSingleELementsOptional object and assign it to the NewOrderSingle for the castor to properly marshall the Java representation of a NewOrderSingle back out to FIXML.
> > > > > >
> > > > > > Below is some sample code:
> > > > > > -----------
> > > > > > NewOrdSingle ord = new NewOrdSingle();
> > > > > > …
> > > > > > NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
> > > > > > ord.setNewOrderSingleElementsOptional( noseo);
> > > > > > ------------
> > > > > > I have to create an empty object even though I am not setting any optional elements.
> > > > > >
> > > > > > Not a huge issue until you start worrying about how fast I can process and route thousands of orders and executions.
> > > > > >
> > > > > > Gerry Capone
> > > > > >
> > > > >
> > > >
> > >
> >
>

Topic		Replies	Views
cardinality issue from B2BITS imported , fixml_schema , xid_165241	4	11	September 30, 2003
Consider flattening header? imported , fixml_schema , xid_165216	4	8	November 25, 2003
tedious XML parsing imported , fixml , xid_164851	16	17	December 8, 2004
FIX 4.1 Repeating Groups imported , general-qa , xid_167351	9	176	March 6, 2013
Experimental Schema available imported , fixml_schema , xid_165252	1	61	August 20, 2011

Optional and Custom Elements minOccurs set to 0?

Below is some sample code:

NewOrdSingle ord = new NewOrdSingle(); … NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional(); ord.setNewOrderSingleElementsOptional( noseo);

Related topics

NewOrdSingle ord = new NewOrdSingle();
…
NewOrderSingleElementsOptional noseo = new NewOrderSingleElementsOptional();
ord.setNewOrderSingleElementsOptional( noseo);