Author |
Message
|
sapana |
Posted: Wed Jul 08, 2009 11:14 pm Post subject: Differentiate Null and empty values for XML element |
|
|
Apprentice
Joined: 16 Apr 2007 Posts: 33 Location: Pune
|
Hi,
I have observed following regarding empty XML elements in a message:
1] For an incoming message, elements of type:
<tag/> and <tag></tag> are treated as identical and the value is "" (empty string).
2] While, if you want to create <tag/> form of element in output message, specify it as :
SET OutputRoot.XMLNS.Message.tag.(XML.Content) = NULL;
So though the content has been specified as NULL, if another flow reads this message, it would interpret it as empty element with value "". Isnt this little strange?
Also, is this behavior message domain dependent?I mean does XMLNSC parser and MRM parser differ in their behaviour for above cases? |
|
Back to top |
|
 |
kimbert |
Posted: Thu Jul 09, 2009 1:10 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
XMLNSC strictly follows the W3C XML standard, which says that <a/> and <a></a> mean exactly the same. The recommended way to indicate an explicit null value in XML is to use xsi:nil - also supported by XMLNSC.
From http://www.w3.org/TR/REC-xml/#sec-starttags
[Definition: An element with no content is said to be empty.] The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag. [Definition: An empty-element tag takes a special form:]
XMLNS may well allow the two cases to be distinguished, and if you find that useful then maybe you should use XMLNS. But bear in mind that you are going out on a limb by assigning a meaning to the rendering style of the empty tag. |
|
Back to top |
|
 |
sapana |
Posted: Fri Jul 10, 2009 12:04 am Post subject: |
|
|
Apprentice
Joined: 16 Apr 2007 Posts: 33 Location: Pune
|
kimbert wrote: |
XMLNS may well allow the two cases to be distinguished, and if you find that useful then maybe you should use XMLNS. But bear in mind that you are going out on a limb by assigning a meaning to the rendering style of the empty tag. |
SET OutputRoot.XMLNS.Message.tag.(XML.Content) = NULL;
Actually I came across this sample esql statement in message broker documentation. Verified using XMLNSC also.
What is confusing me is, when this message is parsed by another message flow, content of this tag would be empty string(seems to be incosistent).
So while creating message using esql, arent we treating elements of form <tag></tag> and <tag/> differently?
Also, can we conclude that, if an element doesnot exists in input XML message, only then its value can be taken to be NULL? |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Fri Jul 10, 2009 12:59 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
sapana wrote: |
Also, can we conclude that, if an element doesnot exists in input XML message, only then its value can be taken to be NULL? |
No, reread the first line of Kimberts response until you understand it. |
|
Back to top |
|
 |
vj13 |
Posted: Wed Jul 03, 2013 8:12 am Post subject: XMLNSC/DFDL Parser issue |
|
|
Newbie
Joined: 03 Jul 2013 Posts: 2
|
Am facing similar problem. We are on MB Version: 8.0.0.2. Have web service which accepts XML input using SOAP. The XML input is validated in SOAPInput node with corresponding XSD. We have defined validations on the XML elements by defining patterns using DFDL editor. The XSD defination is something like this
<A>
<B></B>
<C></C>
</A>
B and C are of type string and B and C have pattern defined as \d{1,8} which makes B and C mandatory fields.
All is well as long as the incoming XML is like this with B and C being empty elements.
<A>
<B></B>
<C></C>
</A>
We get a list of exceptions (SOAPInput node - Validation - Failure Action is set to Exception List) with information like
Text:CHARACTER:cvc-pattern-valid: The value "" is not valid with respect to the pattern facet for type "#Anonymous"
- we get this for each mandatory element and which we eventually are handling in a fault node.
However, when incoming XML is like below
<A>
<B/>
<C/>
</A>
The parser throws a different type of error at level A as below
Insert
Type:INTEGER:5
Text:CHARACTER:cvc-complex-type.2.4.g: The content of element "B" is not complete. Empty tag is not expected since the content type is not 'empty'.
Questions is, both XML formats are supposed to be the same as per XML stanadards. But why WMB parser is treating these differently?
Any insight is appreciated.
Thanks |
|
Back to top |
|
 |
kash3338 |
Posted: Wed Jul 03, 2013 9:23 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009 Posts: 709 Location: Chennai, India
|
Looks like a duplicate of this.
vj13 wrote: |
Any insight is appreciated. |
Hope the insight is provided there. |
|
Back to top |
|
 |
vj13 |
Posted: Wed Jul 03, 2013 10:22 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2013 Posts: 2
|
Yes it is. But no considerable solution is found yet. |
|
Back to top |
|
 |
|