| Author |
Message
|
| mhow |
 Posted: Mon Jan 21, 2002 2:08 pm Post subject: |
 |
|
Newbie
Joined: 13 Jan 2002
Posts: 3
|
We are using XML messages within XML domain. It seems when we recieve message with any extra special character (white space or carriage return) between XML tags, MQSi is unable to parse it and treats message as BLOB. Is it possible to change XML parser setting so that it can ignore spaces etc.?
Thanks
|
|
| Back to top |
|
 |
| mpuetz |
| Posted: Tue Jan 22, 2002 2:27 am Post subject: |
|
|
Centurion
Joined: 05 Jul 2001
Posts: 149
Location: IBM/Central WebSphere Services
|
Hi,
the XML parser doesn't ignore whitepspace and it even doesn't throw
it away during parsing, but rather creates (XML.whitespace) elements
in your message tree. This can cause problems, iy you try to access
elements using unqualified wildcards, e.g.
SET x = InputBody.A.*[1]
to access the first child of the subtree below A. With XML this is
usually not what you want, because it could be whitespace element.
With the XML-parser I recommend you always use *qualifying* wildcards
like this
SET x = InputBody.A.(XML.tag)[1]
which returns the first XML tag element below A or
SET x = InputBody.A.(XML.attr)[1]
which returns the first attribute of element A.
I hope this helps.
_________________
Mathias Puetz
IBM/Central WebSphere Services
WebSphere Business Integration Specialist |
|
| Back to top |
|
|
| longnguk |
| Posted: Wed Aug 16, 2006 2:55 pm Post subject: |
|
|
Novice
Joined: 16 Aug 2006
Posts: 19
Location: Phoenix
|
Does anybody know how to 'translate' the ESQL statements provided by Mathias as shown here:
| Code: |
| SET x = InputBody.A.(XML.tag)[1] |
to its Java equivalent?
I am trying to avoid whitespaces while accessing the 'real' elements within an XML tree in JCN, yet my initial impression is that the XML tree has to be traversed using getNext/PreviousSibbling() methods.
Thanks, |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 16, 2006 4:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Use XMLNSC. That's the compact parser.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Aug 17, 2006 2:26 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Seconded. If on v6, always use XMLNSC, even if you're not having these problems. You'll get better performance, and you'll be better positioned for the future. |
|
| Back to top |
|
|
| longnguk |
| Posted: Thu Aug 17, 2006 9:02 am Post subject: |
|
|
Novice
Joined: 16 Aug 2006
Posts: 19
Location: Phoenix
|
Thank you Jeff, Kim,
I will try it out and let you know the result |
|
| Back to top |
|
|
| longnguk |
| Posted: Thu Aug 17, 2006 10:54 am Post subject: |
|
|
Novice
Joined: 16 Aug 2006
Posts: 19
Location: Phoenix
|
It works! Setting the MQInput node to use XMLNSC domain strips out all the whitespaces...
However, within my buggy test message flow I used an RCD to reset incoming messages to using XMLNS domain, and as a result, whitespaces reappear after the RCD node!
I can only assume that, internally, WMB retains a copy of the original message tree as to be able to retain whitespaces, true?
e.g.
input message
| Code: |
| \n\t<document>\n\t<hd1>Heading 1</hd1>\n\t</document>\n\t |
after MQInput node (set to use XMLNSC)
| Code: |
| <document><hd1>Heading 1</hd1></document> |
after RCD node (immediately follows MQInput node and set to use XMLNS domain)
| Code: |
| \n\t<document>\n\t<hd1>Heading 1</hd1>\n\t</document>\n\t |
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 17, 2006 11:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
XMLNS != XMLNSC.
XMLNSC strips whitespaces, XMLNS doesn't.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Aug 18, 2006 12:36 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| ...whitespaces reappear after the RCD node! I can only assume that, internally, WMB retains a copy of the original message tree as to be able to retain whitespaces, true? |
No - but it probably retained and used a copy of the original bitstream. Nothing to do with whitespace - but message broker will not change the bitstream if you don't alter the message tree. So when it propagated the message to the RCD node, it propagated the original bitstream. XMLNSC parsed it, found the whitespace, and put it in the tree. All of this assumes that you did not alter the message while it was in the XMLNSC domain, of course. |
|
| Back to top |
|
|
| longnguk |
| Posted: Fri Aug 18, 2006 9:08 am Post subject: |
|
|
Novice
Joined: 16 Aug 2006
Posts: 19
Location: Phoenix
|
| Thank you, Kim, the explanation makes sense. On the other hand, it begs a question about efficiency, i.e. the message tree is re-constructed everytime it enters a new node as opposed to the re-construction only occurs when an element within is being altered. Just a thought! |
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Aug 19, 2006 12:54 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| it begs a question about efficiency, i.e. the message tree is re-constructed everytime it enters a new node |
Right and wrong. It's all about efficiency. Message broker leaves parsing to the last possible microsecond, just in case it might be avoidable. In your example it never did parse the message using the XMLNSC parser, so the strategy worked nicely. It does not 'reconstruct' the message tree for every node, though. It just passes the already-constructed tree to the next node. |
|
| Back to top |
|
|
|
|
