| Author |
Message
|
| Yanghui |
 Posted: Thu Jul 03, 2003 7:52 am Post subject: CRLF(x'0D0A) is changed to LF(x'0A) in Environment tree |
 |
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi,
I am using XML domain in WMQI2.1+CSD4 on W2K. I got a strange problem of using Environement tree. In my message flow, the whole incoming XML is made a copy into the environment tree. I found each CR(x'0D) would be taken away for those XML element values with CRLF in it. Does anybody have any idea what's happening here? Why has Environment tree changed the value of XML elements? I don't think there is any data conversion problem since everything is on W2K.
Many thanks in advance.
Regards
-Yanghui |
|
| Back to top |
|
 |
| Craig B |
| Posted: Thu Jul 03, 2003 8:51 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
I do not believe that it is the copying of your XML message to the Environment tree that is changing the x'0D0A' to just x'0A'. To copy the XML message tree to the Environment tree then the XML parser would have had to parse the message bitstream to create the XML message tree. The XML specification (section 2.11) states that x'0D0A' characters will be normalised into x'0A' characters, and so your carriage returns are removed. Therefore the XML parser is working as designed when it does this.
It should also be noted that if the message flow does not change the message tree during a flow, and then an MQOutput node is encountered, then a new output message is not created and it just uses the same one that came in. In this scenario the output message would be as though the XML parser never parsed it, so you would get your carriage returns and line feed characters preserved in the output message.
_________________
Regards
Craig |
|
| Back to top |
|
|
| Yanghui |
| Posted: Thu Jul 03, 2003 9:55 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Thanks a lot for your response. It does make sense.
Unfortunately my incoming XML tree won't stay after the copy is made in the Environment tree. And also before a final message reaches an MQOutput node, msgflow working domain has been changed many times. What I need here is correct values in incoming XML.
So, if the x'0D0A' is supposed to be changed to x'0A' after using generic XML parser, then it seems I have to change x'0A' back to x'0D0A' in the copy before the value is employed in the message processing. Is my understanding correct? Is there a better way of dealing with this?
Thanks againg
-Yanghui |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jul 03, 2003 11:37 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
are the CRLF's within the data? then you can prevent this by using the CDATA section of XML this will leave the content of your XML data untoched.
Michael |
|
| Back to top |
|
|
| Yanghui |
| Posted: Fri Jul 04, 2003 1:06 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Thanks for your response.
Yes. Those CRLFs are within the data.
My understanding about XML CDATA section is for those string which could be mis-recongized as markup. I am not sure if how easy for source application to generate XML with CDATA section in it. For sure it's an option but to me it's a kind of using cow knife to deal with chicken. What do you think? Any more suggestion? Thanks again.
Regards
-Yanghui |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Jul 04, 2003 4:41 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
There are always more sides to a story, so what are those CRLF's doing in your data anyway, if it is free text then the receiver should decide how to format the data to fit into their text fields, if is meant to distinguish between lines in an address for example (so formatted data) then the XML should reflect that (i.e. LineItem)
just my 2 cents, If you don't want the parser to manupulate your data use CDATA and you can still use the data for other purposes.
Michael |
|
| Back to top |
|
|
|
|
