Hello all. I have a situation where I have a single string that I need to break up into separate fields to create xml values.

The incoming data has escaped characters in a mix of amp, quote, gt, lt and apos.

Lets say I have the following:
$PARM,40,256 = 'Test Description < '
$PARM,296,2 = 'OK'

When I do the following:
<xsl:variable name="FIELD1" select="substring($PARM,40,256)"/>

FIELD1 contains 'Test Description &lt;' + whitespace + 'OK'

Any subsequent substrings that I do to other fields are then corrputed by the offset created beyond position 256.

Anything I can do to address this. I am using Xalan for the parser.

Regards.

Your string does not contain the four characters &,l,t,; - it contains the single character <. Remember that XSLT is always working on the data model created by parsing your XML source, not on the XML source in its lexical form.



Michael Kay
http://saxon.sf.net/

Thanks Michael. I understand what it is reading, my question really should have been - how do I trick him into doing something different?

I am trying to cope with a limitation of our process(es). The data is sourced from a fixed format data source and wrapped in <message> tags, so the data *has* to be pre-escaped at source.

So, looking for advice here, if there is no way of doing it via just substrings (as I was attempting) because of what the parser does, is it then possible to pre-process the string before I start substringing so that the real offsets to the data can be maintained? Dynamic positioning based on existence of escaped characters perhaps?

Cheers....

I don't think you understood my previous reply. The XSLT processor has absolutely no idea whether a character was originally written as ">" or "&gt;" or "#x3E;" or "#00000000062;". It is working on the real textual value of the node, not on the escaped representation used in the lexical XML.



Michael Kay
http://www.saxonica.com/

Thanks Michael. Yes, I understood your inital reply (grateful - thanks), and understand your second reply.

What I was looking for was advice on if the escaped representation did appear in my incoming data and I needed to parse it based on known lengths, then I would have to dynamically calculate the start and end positions if I found escaped characters in the string.

While I believe someone must have come up against this in the past and found a solution, I figured that this is just too much effort for little reward. In the end I kicked back to the source application owners, with "do us a favour and wrap your free-form special character data in tags so I don't have to give a stuff where it is positionally".

Works like a charm now ;)

Cheers