RE: [Quickfix-developers] Re: empty tag

[<Ani...@rb...>]

My two cents.
From business point of view, I believe an empty (standard) tag has no meani=
ng, so I believe, the current behavior of allowing an empty tag is merely a=
  technical fix to avoid the contentious issues you mention below  viz.
  i) Missing an expected tag
 ii) Removing an existing valid value tag
iii) Containing an incorrect (previous) value
=20
Possible Resolutions:
A) Configuration of allowing/disallowing in general carries the same surpri=
se elements
B) Configuring for a specific tag may be more desirable as it is a publishe=
d and managed resolution
C) Configuring for a specific tag for a New/Cancel/Replace) may be even mor=
e desirable
D) Configure to simply ignore empty values
E) Configure to ignore empty values with warning
=20
In my view default behavior as it exists now and with C and E  or B & E is =
desirable.
=20
Thanks,
=20
Anil

-----Original Message-----
From: qui...@li... [mailto:quickfix-deve=
lop...@li...]On Behalf Of Oren Miller
Sent: Tuesday, July 05, 2005 10:17 AM
To: Alvin Wang
Cc: qui...@li...; quickfix-developers-admin@li=
sts.sourceforge.net
Subject: Re: [Quickfix-developers] Re: empty tag


My concern is how to handle the situation where the field already exists.  =
If field 58 is set in the message, and I set it again with a field that has=
 an empty tag, what does this mean?  Does it mean that I ignore the new fie=
ld and retain the old value?  Or do I remove the old field from the message=
 completely.  In which case setting a field with an empty tag is the same b=
ehavior as calling removeField.  Both of these behaviors feel a little surp=
rising to me.  I'd be interested in hearing other opinions on this.
=20
--oren

----- Original Message -----=20
From: Alvin Wang <mailto:AW...@FF...> =20
To: Oren Miller <mailto:or...@qu...> =20
Cc: qui...@li... ; quickfix-developers-admin@l=
ists.sourceforge.net=20
Sent: Tuesday, July 05, 2005 9:40 PM
Subject: [Quickfix-developers] Re: empty tag



Oren, I can understand where you are coming from. It makes total sense if Q=
F throws NoTagValue exception in this case. However, I just feel it will ad=
d workload to the developers and the production may become disruptive.=20

Thanks=20
Alvin=20





	"Oren Miller" < or...@qu...>=20


07/05/2005 10:00 AM=20


       =20
        To:        < qui...@li...>, < quickfix=
-dev...@li...>, "Alvin Wang" < AW...@FF...>=20
        cc:        =20
        bcc:        =20
        Subject:        Re: empty tag=09



We could, although more likely I would throw a NoTagValue exception.  I don=
't much like the idea of having QF silently ignoring a field that the devel=
oper would be expecting to go out in the message (much like I don't like th=
e current behavior).  I can imagine the head scratching that would go on if=
 they added a field and then found it mysteriously absent in the logs.=20
 =20
In either case if you have a field that might contain a blank value, I woul=
d suggest checking it before adding it to a message.=20
 =20
--oren=20
----- Original Message -----=20
From:  <mailto:AW...@FF...> Alvin Wang=20
To:  <mailto:qui...@li...> quickfix-developers=
@lists.sourceforge.net ;  <mailto:qui...@li...=
ge.net> qui...@li...=20
Cc:  <mailto:or...@qu...> Oren Miller=20
Sent: Tuesday, July 05, 2005 9:10 PM=20
Subject: empty tag=20


HI=20

If I set a tag as below:=20
message.set(new Text(text));=20
and if the variable "text" is null. QF will include an empty tag 58. As a r=
esult, some FIX engine (such as QF itself) on the other end will reject the=
 message.  Can QF skip including empty tag?=20

Thanks=20
Alvin *********************************************************************=
* This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. Disclo=
sure to anyone other than the intended recipient is prohibited. If you are =
not the intended recipient, please do not disseminate, distribute or copy t=
his communication, by e-mail or otherwise. Instead, please notify us immedi=
ately by return e-mail (including the original message with your reply) and=
 then delete and discard all copies of the message. We have taken precautio=
ns to minimize the risk of transmitting software viruses but nevertheless a=
dvise you to carry out your own virus checks on any attachment to this mess=
age. We accept no liability for any loss or damage caused by software virus=
es. **********************************************************************=
=20




<font face=3D"Times New Roman" size=3D"3">
<p>------------------------------------------------------------------------=
------</p>
<p> This E-Mail (including any attachments) may contain privileged or confi=
dential information.  It is intended only for the addressee(s) indicated ab=
ove. The sender does not waive any of its rights, privileges or other prote=
ctions respecting this information.  Any distribution, copying or other use=
 of this E-Mail or the information it contains, by other than an intended r=
ecipient, is not sanctioned and is prohibited. If you received this E-Mail =
in error, please delete it and advise the sender (by return E-Mail or other=
wise) immediately.</p>
<p> This E-Mail (including any attachments) has been scanned for viruses.  =
It is believed to be free of any virus or other defect that might affect an=
y computer system into which it is received and opened.  However, it is the=
 responsibility of the recipient to ensure that it is virus free.  The send=
er accepts no responsibility for any loss or damage arising in any way from=
 its use.</p>
<p> E-Mail received by or sent from RBC Capital Markets is subject to revie=
w by Supervisory personnel.  Such communications are retained and may be pr=
oduced to regulatory authorities or others with legal rights to the informa=
tion.</p>
<p>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D</p>
</font>