Hi Arun,
This style of NSQL parameter is the style that was used in grid and graph portlets before mapped attribute parameters were available to use in Studio queries and objects (note: small typo on integer occurred too):
@where:param:xml:Integer:/data/id/@value@
For grid and graph portlets, you should consider using mapped attribute parameters where possible.
With an Xcelsius portlet it is a bit different though; the data for the NSQL isn't being read and processed by the inner Clarity code for producing a HTML page directly on screen, instead the Xcelsius dashboard inside a Shockwave Flash (.swf) file on the client browser, makes a web service call to Clarity to fetch and parse the XML results of an NSQL query.
As such, the passing of parameters works a little differently.
In Xcelsius Designer, under the Data Manager you define your web services that you will be querying, and that will pull back any 'traditional' NSQL WHERE constructs of the form: @WHERE:PARAM:USER_DEF:INTEGER:CURRENT_INVESTMENT_ID@ (for example).
This CURRENT_INVESTMENT_ID (possibly prefixed with param_ I forget offhand sorry) will exist in the web service definition as a possible filter field, usable in all web service requests to the query (via SOAP / XOG / etc.). Your portlet/dashboard's definition in Clarity can then have an Object parameter assigned to it, mapped to a flash variable, that will pass in the correct ID value, which in turn you then pass to the web service filter field through your data connections in the Xcelsius Designer.
Look at the out of the box Portfolio Dashboard interactive portlet and design files to see how it is doing the same thing with the portfolio ID.
The exact screens/terms/positions for the definitions of the data connection and parameter mapping inside Xcelsius Designer escape me, but hopefully you'll be able to use this and follow the portfolio example to see where I'm coming from.
-Nick