| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| XMLNSC parses opaque elements |
« View previous topic :: View next topic » |
| Author |
Message
|
| Esa |
 Posted: Thu Mar 10, 2011 2:28 am Post subject: XMLNSC parses opaque elements |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Hello!
I searched the forum and did not find much discussion about opaque parsing.
It seems to me that opaque parsing means just that opaque elements are not parsed into an element tree but into a single string value. But they are always parsed, not copied into a byte array as one would think.
MB V7 infocenter states like this about opaque parsing (http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac20990_.htm):
| Quote: |
Use the property Opaque Elements on the Parser options page of the relevant message flow node to specify the elements that you want to be parsed opaquely. This property specifies a list of element names. If an element in the input XML message is named in this list, the element is parsed as a single string.
An opaque element cannot be queried like an ordinary element; its value is the segment of the XML bit stream that belongs to the element, and it has no child elements in the message tree, even though it can represent a large subtree in the XML document. |
| Quote: |
| Using opaque parsing has some drawbacks. When opaque parsing is enabled, some parts of the message are never parsed, and XML that is either badly formed or not valid is allowed to pass through the message flow without being detected. |
The latter quote does not seem to be correct. No matter how hard I have tried, I haven't managed to pass invalid XML through a message flow in an opaque element.
Exept by doing
| Code: |
| SET OutputRoot = InputRoot; |
but that passes invalid XML throuhg even when you don't use opaque elements. Because it does a memcopy and does not actually parse the message, I suppose.
But if you have somewhere in your input message an opaque element with invalid XML even this code fails with parser exception:
| Code: |
| Set OutputRoot.XMLNSC.document = InputRoot.XMLNSC.document; |
|
|
| Back to top |
|
 |
| kimbert |
| Posted: Thu Mar 10, 2011 3:34 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| No matter how hard I have tried, I haven't managed to pass invalid XML through a message flow in an opaque element. |
You may need to try a little harder 
Certain types of badly-formed message will trip up the parser wherever they appear. A missing end tag will definitely do it. An illegal XML character will definitely do it. But an idref attribute that refers to a missing id would not be detected. To put it simply, the parser needs to be able to *reliably* find the end of the opaque element, and it will complain if it cannot *reliably* do that.
Going a little further, all schema validation is completely suspended for an opaque element. So undeclared child tags, missing required child tags and facet validation errors will all go undetected in an opaque element.
I don't know what your objective is, but it is worth reminding all readers that the opaque elements feature is for performance. It should never be used to get badly-formed XML through your message flow. There are other ways to do that - ways that do not depend on a broker-specific feature. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 10, 2011 3:55 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| kimbert wrote: |
Certain types of badly-formed message will trip up the parser wherever they appear. A missing end tag will definitely do it. An illegal XML character will definitely do it. But an idref attribute that refers to a missing id would not be detected. To put it simply, the parser needs to be able to *reliably* find the end of the opaque element, and it will complain if it cannot *reliably* do that.
|
Yes, a missing end tag is exactly what I tried. So, just scanning the input bytestream for the next occurrence of the opaque elements end tag is not considered *reliable*? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 10, 2011 4:40 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
So, just scanning the input bytestream for the next occurrence of the opaque elements end tag is not considered *reliable*?
|
Correct. It's not reliable because
- the thing that looked like the end tag might be contained within a CDATA section
- the end tag might be ending a nested occurrence of the tag, not the outermost tag ( i.e. the opaque tag might contain another tag with the same name ).
The XML implementation in XMLNSC is rigorous and standards-compliant. We are not going to sacrifice those objectives in order to satisfy a very questionable requirement ( not that you have claimed that this is a requirement, to be fair to you ). |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 10, 2011 4:51 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| kimbert wrote: |
| We are not going to sacrifice those objectives in order to satisfy a very questionable requirement ( not that you have claimed that this is a requirement, to be fair to you ). |
Oh, yes. This is a requirement to correct these lines in the infocenter:
| Quote: |
| Using opaque parsing has some drawbacks. When opaque parsing is enabled, some parts of the message are never parsed, and XML that is either badly formed or not valid is allowed to pass through the message flow without being detected. |
Maybe like this:
| Quote: |
Using opaque parsing has some drawbacks. When opaque parsing is enabled, some parts of the message are not parsed completely, and XML that is either badly formed or not valid may be allowed to pass through the message flow without being detected, if you are lucky.  |
|
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 10, 2011 7:29 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Fair enough - but the difference is very small, and the error is on the right side. There is a risk that someone tries to verify the statement in the infocenter and get puzzled. I don't see any other risk to a user arising from this. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
