Hi, Having a bit more of a think.... If you are working to a schema, and the format of the xml currently in Value is not clearly definable then, if you can change the schema, you could just use an xs:any element (with maxOccurs="unbounded") to define the nested xml but place it within the Variable element. If there is no schema then you could just move the xml as above anyway, with no worries about schema changes. So there is no need for a CDATA section really. Of course in either case you may be exchanging this data with someone else, who you may or may not be able to get agreement with :) If you can't move the 'encoded' xml, and presuming it is all properly escaped, I think maybe the place to start is to select the Value attribute into a variable. This would contain a tree fragment that you can perform all the usual xslt stuff on. For instance you could set up a template with a match of ALL_RESULTS, you could call the template with apply-templates with a select on the variable you have created. If that doesn't work then perhaps you could pass the variable into a param of the template and process it that way. I dont think it matters that the source for the variable is text containing < as opposed to < etc, the xslt processor can't tell the diference, I think :-D Sorry I dont have time to test out the theory - I would be interested to hear how you get this to work.. Cheers Phil Hobgen barbari.co.uk Southampton, UK
