| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| XMLNSC parser error - multiple default namespaces |
« View previous topic :: View next topic » |
| Author |
Message
|
| hdomin257 |
 Posted: Fri Nov 27, 2020 8:57 am Post subject: XMLNSC parser error - multiple default namespaces |
 |
|
Newbie
Joined: 27 Nov 2020
Posts: 7
|
Hello,
I have strange problem with default namespaces in XMLNSC domain. Consumer's aplication sends data like this:
| Code: |
<RootReq xmlns="hhtpdomain/bla/bla/ble/v3/req">
<ChildA>
<ChildB xmlns="httpdomain/bla/bla/blu">16</ChildB>
<ChildC xmlns="httpdomain/bla/bla/blu">2</ChildC>
<ChildD [b]xmlns="httpdomain/bla/bla/blu"[/b]>fhasyfas</ChildD>
<ChildE xmlns="httpdomain/bla/bla/blu">
<ChildF>4067</ChildF>
</ChildE>
</ChildA>
</RootReq> |
The problem is, that our (external) validation does not catch it like a validation error agains xsd schema. Same like other external validation tools eg. oxygen xml developer, or online tools etc.
But XMLNSC parser gives me this parser exception:
XML Writing Errors have occurred
mbXMLNSCWriter::writeElement
Element must have a namespace specified if there is a default namespace in scope (ChildD)
When default namespace on ChildD is removed it works fine. I'm wondering why is it like that. Why the problem is not on ChildB or ChildC which have the same default namespace like ChildD. And why some validators marks it as valid XML, but XMLNSC parser can't hadle it.
I'm not an XML expert and It is probably stupid way to send input XML like that, but I'm curious why this occurs. And how to think about it
IIB 10.0.0.something |
|
| Back to top |
|
 |
| timber |
| Posted: Sat Nov 28, 2020 12:45 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Thanks for a clear problem statement, and thanks for quoting the error in full as well.
This is not a schema validation error - the XMLNSC parsing is not attempting to check the document against the XSD. So no need to spend any more time checking against other XML validators.
Also, this is not a parsing error, so the input document is probably not relevant. The error is being reported when the XMLNSC domain tries to convert OutputRoot.XMLNSC into an XML document. So the really interesting piece of information is the contents of OutputRoot.XMLNSC.
Please can you
- add a Trace node at the end of the message flow, and capture the contents of OutputRoot.XMLNSC. Set the Pattern property to ${Root}
- Do not take the shortcut of posting the debugger output - that would be useless because it does not show the namespaces.
- post the output of the Trace node.
Take care to remove any commercially sensitive information from the Trace node output before posting, obviously. |
|
| Back to top |
|
|
| hdomin257 |
| Posted: Sun Dec 13, 2020 1:34 am Post subject: |
|
|
Newbie
Joined: 27 Nov 2020
Posts: 7
|
Thank You timber a lot.
You pointed me to the right direction. I did not realize that it is XML Writing Error - even at the time I was copying it here.
I blindly focused on Input data - It worked without ChildD default namespace. And It's logical, because there was Set something.something = something.*:ChildD statement, which caused the error.
I was fooled by our loger and two consecutive propagations, which pointed me to wrong compute module
thx a lot again and sorry for the late reaction. |
|
| 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
|
|
|
|
