Author |
Message
|
servi |
Posted: Mon Apr 21, 2008 7:37 am Post subject: How force character scape under XML Transformation Node |
|
|
 Novice
Joined: 19 Mar 2008 Posts: 22 Location: Madrid, España
|
In WBI v5.3 all the special characters transformed by a XML Transformation node in a not Unicode Encoding was scaped. ¿How I can have the same behaviour on WBI v6.1?
MsgFlow:
InputNode(XML)->XML_Transformation(cp-858)->ReplyNode
Input: <?xml version="1.0"?><XML><Country><![CDATA[ESPAÑA]]></Country></XML>
XSL:
<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<XML>
<xsl:copy-of select="child::XML/*"/>
</XML>
</xsl:template>
</xsl:stylesheet>
Output with WBI v5.2: <XML><Country>ESPAêA<Country><XML>
Output with WBI v6.2 :
<?xml version="1.0" encoding="UTF-8"?><XML><Country>ESPAÑA</Country></XML> |
|
Back to top |
|
 |
kimbert |
Posted: Mon Apr 21, 2008 12:09 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Is this a question about message broker, or some other product?
If message broker, which version? ( you mentioned 'WBI v6.1' and 'WBI v6.2' )
Assuming that you are using WebSphere Message Broker v6.1...
- You should not be using the XML domain in a new message flow.
Please switch to XMLNS or XMLNSC as part of the migration.
- You need to find out where the problem is being introduced. Please put a Trace node after the XML Transformation node.
- Please check that Root.Properites.CodeCharSetID is correct in the output message tree. |
|
Back to top |
|
 |
servi |
Posted: Mon Apr 21, 2008 11:27 pm Post subject: |
|
|
 Novice
Joined: 19 Mar 2008 Posts: 22 Location: Madrid, España
|
Excuse the misprint . I am using WebSphere Message Broker v6.1. And the question is how can i get the especial characters escaped.
I'm migrating an XML Transformation node from Message Broker v5.2 to v6.1. Before all output special characters was escaped to the equivalent Unicode character entity, but in Broker v6.1 all characters are printed directly (also in XMLNSC dominium).
When XMLTransformation Node OutputCodeCharSet is not 1208(UTF-8 ) or 1200 (Unicode), in Broker v5.1, outputs messages was escaped:
HOL& #229; ESPA& #209;A
In Broker version v6.1 (with the same OutputCharacterSet 858), outputs message doesn't have characters entities:
HOLå ESPAÑA
Probably is better if XML/XMLNSC message doesn't have characters entities inside, but we need it to achieve the migration requirement of transparence.
Thanks for your help.  |
|
Back to top |
|
 |
kimbert |
Posted: Tue Apr 22, 2008 1:43 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
In Broker version v6.1 (with the same OutputCharacterSet 858), outputs message doesn't have characters entities: |
I'll take a guess. The XML transformation engine has been upgraded, and it no longer escapes characters unless it *needs* to.
If the output XML is well-formed ( you can easily check that by attempting to load it into a browser ) then there is no problem. The document being output by v6.1 is equivalent to ( has the same meaning as ) the document that was output by v5.2. |
|
Back to top |
|
 |
servi |
Posted: Tue Apr 22, 2008 2:22 am Post subject: |
|
|
 Novice
Joined: 19 Mar 2008 Posts: 22 Location: Madrid, España
|
Thanks a lot for your reply. I know both outputs are equivalent in XML terms, but not similar. This means we must check the behaviour of all clients application (which developers aren't usually w3c acolyte).
It would be usefull if this XMLTransformation behaviour was an option of the node. That's life!  |
|
Back to top |
|
 |
Vitor |
Posted: Tue Apr 22, 2008 2:44 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
servi wrote: |
This means we must check the behaviour of all clients application (which developers aren't usually w3c acolyte).
|
Only if they've written their own XML parser. Not impossible, and a trout is the only recourse.
Any of the commerical / open source parsers will see these as the same. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
kimbert |
Posted: Tue Apr 22, 2008 3:18 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
which developers aren't usually w3c acolyte |
An XML parser implements the XML specification. If it does not, then it is not an 'XML parser'.
I agree with Vitor. If anybody writes their own XML parser and does a bad job of it, they deserve the inevitable pain. It's not as if it's difficult to use a ready-made XML parser library ( xerces, for instance ). |
|
Back to top |
|
 |
Vitor |
Posted: Tue Apr 22, 2008 3:26 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
kimbert wrote: |
If anybody writes their own XML parser and does a bad job of it, they deserve the inevitable pain. |
If you reinvent the wheel, expect to be strapped to it & taken for a ride...  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|