Return-Path: 
 <dev-return-7253-apmail-synapse-dev-archive=synapse.apache.org@synapse.apache.org>
Delivered-To: apmail-synapse-dev-archive@www.apache.org
Received: (qmail 66433 invoked from network); 1 Jul 2008 18:16:31 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 1 Jul 2008 18:16:31 -0000
Received: (qmail 38280 invoked by uid 500); 1 Jul 2008 18:16:31 -0000
Delivered-To: apmail-synapse-dev-archive@synapse.apache.org
Received: (qmail 38241 invoked by uid 500); 1 Jul 2008 18:16:31 -0000
Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@synapse.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@synapse.apache.org>
List-Post: <mailto:dev@synapse.apache.org>
List-Id: <dev.synapse.apache.org>
Reply-To: dev@synapse.apache.org
Delivered-To: mailing list dev@synapse.apache.org
Received: (qmail 38230 invoked by uid 99); 1 Jul 2008 18:16:31 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jul 2008 11:16:31 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of ruwan.linton@gmail.com
 designates 74.125.44.30 as permitted sender)
Received: from [74.125.44.30] (HELO yx-out-2324.google.com) (74.125.44.30)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jul 2008 18:15:38 +0000
Received: by yx-out-2324.google.com with SMTP id 8so2291yxb.51
        for <dev@synapse.apache.org>; Tue, 01 Jul 2008 11:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:in-reply-to:mime-version:content-type:references;
        bh=vfl8EMpsiFyIGJsV9PLBH3vCoBpzrHW1Z5kXiEavOtM=;
        b=LkRhd07aGKqGKU+IV7NJ57F530QHDhPo0ycukarHeWkD3jNgFFUqZqmgOVuCGA2GOO
         vNKnZP2hXxJADiAoO2xVT+h2D7eZJ2sCa02fxK5n9bbik8x/TaQNYey4TnaW8p7/lyl9
         1rbdGOsSZEi5FKgIDm/Cdzhdtwt5KmdORqNZ8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=d3GsBtKGjcmlFtAzTQwDW+03PRRio77Y2VkitPN4wzop4XzYoW1rr/2Tf91LWhtgqJ
         lBnlHI1COytFIDhfLHX1oZuobxg9vRAbG83ZMuYXe7LGisT1fc4LjgVW7HPg9+Tuqc+g
         AmQphdXS0Mm7FkD2wvbTSKju/YCJEg4FfLZqE=
Received: by 10.142.84.3 with SMTP id h3mr2591401wfb.309.1214936151843;
        Tue, 01 Jul 2008 11:15:51 -0700 (PDT)
Received: by 10.143.19.18 with HTTP; Tue, 1 Jul 2008 11:15:51 -0700 (PDT)
Message-ID: <672a01200807011115w447d7f89nf16fdeea4a416aa4@mail.gmail.com>
Date: Tue, 1 Jul 2008 23:45:51 +0530
From: "Ruwan Linton" <ruwan.linton@gmail.com>
To: dev@synapse.apache.org
Subject: Re: FIX Message Structure maintain inside synapse
In-Reply-To: <486A6F4A.9010806@wso2.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_20129_32214553.1214936151867"
References: <486A0512.5000100@wso2.com>
	 <672a01200807010729g5fc65000g9a84d1b365f9cca8@mail.gmail.com>
	 <486A6F4A.9010806@wso2.com>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_20129_32214553.1214936151867
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Asanka,

On Tue, Jul 1, 2008 at 11:24 PM, Asanka Abeysinghe <asankaa@wso2.com> wrote:

>
> What do you mean by a unique tag id? Are you proposing to keep these field
> elements as attributes? I think this looks better. Or are you referring to
> unique tag names?
>
> I'm referring to unique tag names,
> <CIOrdID>ORD_1</CIOrdID>
> <Qty>1000</Qty>
> <Symbol>SUNW</Symbol>
> <SecurityID>277461109</SecurityID>
> or
> <11>ORD_1</11>
> <43>100</43>
> <55>SUNW</55>
>

OK, this makes sense.... :-) but isn't there a overhead associated with
building and serializing a message in this mechanism?


>
>
>
>>
>> [3] Why it has used CDATA to store value ? (only tag 58 (text) might
>> contain text we have to omit from the XML parser, not a common case)
>>
>
> Isn't these field values are text (strings) always, where there can be '<'
> like characters?
>
> Yes it is text, but a order creation blotter or a order generator will only
> allow to enter free text inside tag 58
>

I am sorry but I didn't get this.


>
>
>
>>
>> The current structure is concerning me because
>> [1] XSLT transformation and CBR make a tough task with the current
>> structure, so it will effect the performance of FIX transformation and CBR.
>>
>
> I don't get this point, as far as this message element is the SOAP payload
> (first child of the SOAPBody) I don't think there is any issue with the XSLT
> nor the CBR.
>
> Message element is the first child of the SOAP payload, but if the FIX tags
> represent as unique tag names we can use a XPath to directly  travel to a
> element and fetch data e.g message/body/symbol, but with repeating elements
> we have to iterate using a  '*xsl:for -each  select*'  to find a specific
> value for a field (Correct me If I'm wrong because I'm not an expert on
> XSLT).
>

No.... You don't have to use xsl:for-each for this. If you want to access
the field element with the id 43 you could use the following xpath to get
the direct access to that node;

//field[@id='43']

This will give you the first element appear in the xml tree with tag name
field and having the attribute id with value 43.

So there is no difference at all with the existing format and proposed new
format for neither XSLTs nor CBRs (XPATH)

Thanks,
Ruwan


>
>
> Asanka A.
>  --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org For additional
> commands, e-mail: dev-help@synapse.apache.org
>



-- 
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/

------=_Part_20129_32214553.1214936151867
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Asanka,<br><br><div class="gmail_quote">On Tue, Jul 1, 2008 at 11:24 PM, Asanka Abeysinghe &lt;<a href="mailto:asankaa@wso2.com">asankaa@wso2.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000"><div class="Ih2E3d">
<blockquote type="cite">
  <div class="gmail_quote">
  <div><br>
What do you mean by a unique tag id? Are you proposing to keep these
field elements as attributes? I think this looks better. Or are you
referring to unique tag names?<br>
  </div>
  </div>
</blockquote></div>
I&#39;m referring to unique tag names, <br>
&lt;CIOrdID&gt;ORD_1&lt;/CIOrdID&gt; <br>
&lt;Qty&gt;1000&lt;/Qty&gt;<br>
&lt;Symbol&gt;SUNW&lt;/Symbol&gt;<br>
&lt;SecurityID&gt;277461109&lt;/SecurityID&gt;<br>
or <br>
&lt;11&gt;ORD_1&lt;/11&gt;<br>
&lt;43&gt;100&lt;/43&gt;<br>
&lt;55&gt;SUNW&lt;/55&gt;</div></blockquote><div><br>OK, this makes sense.... :-) but isn&#39;t there a overhead associated with building and serializing a message in this mechanism?<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="Ih2E3d"><br>
<blockquote type="cite">
  <div class="gmail_quote">
  <div>&nbsp;</div>
  <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000"><br>
[3] Why it has used CDATA to store value ? (only tag 58 (text) might
contain text we have to omit from the XML parser, not a common case)</div>
  </blockquote>
  <div><br>
Isn&#39;t these field values are text (strings) always, where there can be
&#39;&lt;&#39; like characters?<br>
  </div>
  </div>
</blockquote></div>
Yes it is text, but a order creation blotter or a order generator will
only allow to enter free text inside tag 58</div></blockquote><div><br>I am sorry but I didn&#39;t get this.<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="Ih2E3d">
  
  &nbsp;<blockquote type="cite"><div class="gmail_quote">
  <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000"><br>
    <br>
The current structure is concerning me because <br>
[1] XSLT transformation and CBR make a tough task with the current
structure, so it will effect the performance of FIX transformation and
CBR.</div>
  </blockquote>
  <div><br>
I don&#39;t get this point, as far as this message element is the SOAP
payload (first child of the SOAPBody) I don&#39;t think there is any issue
with the XSLT nor the CBR.<br>
  </div>
  </div>
</blockquote></div>
Message element is the first child of the SOAP payload, but if the FIX
tags represent as unique tag names we can use a XPath to directly&nbsp;
travel to a&nbsp; element and fetch data e.g message/body/symbol, but with
repeating elements we have to iterate using a&nbsp; &#39;<b>xsl:for -each&nbsp; select</b>&#39;&nbsp;
to find a specific value for a field (Correct me If I&#39;m wrong because
I&#39;m not an expert on XSLT).</div></blockquote><div><br>No.... You don&#39;t have to use xsl:for-each for this. If you want to access the field element with the id 43 you could use the following xpath to get the direct access to that node;<br>
<br>//field[@id=&#39;43&#39;]<br><br>This will give you the first element appear in the xml tree with tag name field and having the attribute id with value 43.<br><br>So there is no difference at all with the existing format and proposed new format for neither XSLTs nor CBRs (XPATH)<br>
<br>Thanks,<br>Ruwan<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000"><br>
<br>
Asanka A.<br>
</div><div><div></div><div class="Wj3C7c">


---------------------------------------------------------------------
To unsubscribe, e-mail: <a href="mailto:dev-unsubscribe@synapse.apache.org" target="_blank">dev-unsubscribe@synapse.apache.org</a>
For additional commands, e-mail: <a href="mailto:dev-help@synapse.apache.org" target="_blank">dev-help@synapse.apache.org</a>

</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ruwan Linton<br><a href="http://wso2.org">http://wso2.org</a> - &quot;Oxygenating the Web Services Platform&quot;<br><a href="http://ruwansblog.blogspot.com/">http://ruwansblog.blogspot.com/</a>

------=_Part_20129_32214553.1214936151867--