| Author |
Message
|
| Marek |
 Posted: Mon Mar 26, 2007 6:10 am Post subject: XMLNSC Declare Reference bug? Navigate XML Tree 6.0.2 |
 |
|
Apprentice
Joined: 30 Jun 2004
Posts: 32
Location: Edinburgh
|
Background
WMB v.6.0.2 PTF 4
I've been having whitspace issues whist trying to dynamically navigate though an XML tree using the XML parser so I've swaped to the XMLNSC parser. So far so good, however ...
Issue
My initial 'DECLARE p_xmlTree REFERENCE TO InputRoot.XMLNSC.CSL' esql statement always returns Root instead of CSL in variable fieldval. In fact only references to InputRoot.XMLNSC and InputRoot itself return the expected results (XMLNSC and Root respectively).
Does anyone have any experience of this issue?
Code:
| Code: |
DECLARE fieldval char;
DECLARE p_xmlTree REFERENCE TO InputRoot.XMLNSC.CSL;
SET fieldval = FIELDNAME(p_xmlTree) -- Returns Root not CSL as expected!; |
Test XML Message
| Code: |
<CSL version="2.0" xmlns="http://www.123.com/XMLSchema/123" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.123.com/XMLSchema/123 ILChecker.xsd">
<Message type="IL" category="CHECKER">
<List>
<Row key="key" >
<MssgRef>1</MssgRef>
<ProcessingDtTm>2005-09-20T12:00:00</ProcessingDtTm>
</Row>
</List>
</Message>
</CSL> |
Thanks.
IBM Manual Ref.
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ad02430_.htm |
|
| Back to top |
|
 |
| special_agent_Queue |
| Posted: Mon Mar 26, 2007 6:26 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
You have a default namespace, so every element that does not already have a namespace associated with it will use that default namespace. In your code, you should:
| Code: |
| DECLARE someNS NAMESPACE "http://www.123.com/XMLSchema/123"; |
Then you should be able to
| Code: |
| DECLARE p_xmlTree REFERENCE TO InputRoot.XMLNSC.someNS:CSL; |
|
|
| Back to top |
|
|
| msukup |
| Posted: Mon Mar 26, 2007 7:24 am Post subject: |
|
|
Acolyte
Joined: 11 Feb 2002
Posts: 56
|
I have seen the following bug with the xmlnsc parser, which caused me to stop using it in favor of xmlns until it matures a bit:
if an element evaluates to "null", then it seems to be populating with the previous sibling's value rather than the value "null". |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Mon Mar 26, 2007 7:36 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi msukup,
| msukup wrote: |
I have seen the following bug with the xmlnsc parser, which caused me to stop using it in favor of xmlns until it matures a bit:
if an element evaluates to "null", then it seems to be populating with the previous sibling's value rather than the value "null". |
 If the element you are trying to reference to is not found...be it that the field does not exist or if the path given is wrong(as in the above case), the reference will point to the Root...It's not a bug...In such cases you should immediately use the debugger or take a file trace and see what the tree structure looks like and not jump to conclusions...
Regards. |
|
| Back to top |
|
|
| Marek |
| Posted: Mon Mar 26, 2007 7:37 am Post subject: |
|
|
Apprentice
Joined: 30 Jun 2004
Posts: 32
Location: Edinburgh
|
Much appreciated for taking the time to reply.
Your solution works (single quotes round the namespace address).
For the record, initially I tried to just suffix 'xmlns:'. See:
| Code: |
| DECLARE p_xmlTree REFERENCE TO InputRoot.XMLNSC.xmlns:CSL |
However, this attempt of mine did not work.
Thank you. |
|
| Back to top |
|
|
| Marek |
| Posted: Mon Mar 26, 2007 8:22 am Post subject: |
|
|
Apprentice
Joined: 30 Jun 2004
Posts: 32
Location: Edinburgh
|
... and I note that if I want to refer to the Message element I need to code 'someNS:' yet again. See:
| Code: |
| DECLARE p_xmlTree REFERENCE TO InputRoot.XMLNSC.someNS:CSL.someNS:Message; |
Is there a less repetitive way of having to repeat 'someNS:' for every XML element? |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Mon Mar 26, 2007 9:11 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
| Quote: |
| Is there a less repetitive way of having to repeat 'someNS:' for every XML element? |
Make the input message not have a default namespace.
Also, the someNS was only a suggestion, you don't have to use that specific prefix. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Mon Mar 26, 2007 9:15 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
| elvis_gn wrote: |
Hi msukup,
| msukup wrote: |
I have seen the following bug with the xmlnsc parser, which caused me to stop using it in favor of xmlns until it matures a bit:
if an element evaluates to "null", then it seems to be populating with the previous sibling's value rather than the value "null". |
If the element you are trying to reference to is not found...be it that the field does not exist or if the path given is wrong(as in the above case), the reference will point to the Root...It's not a bug...In such cases you should immediately use the debugger or take a file trace and see what the tree structure looks like and not jump to conclusions...
Regards. |
Actually, the XMLNSC parser does have issues with this.
msukup, I have found a workaround for this, and that is to check the fieldtype of the element.
| Code: |
IF FIELDTYPE(theElement) = NameValue THEN set new field equal to this one.
ELSEIF FIELDTYPE(theElement) = Name THEN set new field = NULL or spaces. |
If it has a fieldtype of Name, then it evaluates to NULL, but if you do try and set the new field to it, you are going to get unpredictable results - either whitespace elements, or something else.
Hope this helps. |
|
| Back to top |
|
|
| msukup |
| Posted: Mon Mar 26, 2007 1:07 pm Post subject: |
|
|
Acolyte
Joined: 11 Feb 2002
Posts: 56
|
| thanks, special agent! I'll make sure to use this workaround. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Mar 26, 2007 2:17 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| msukup wrote: |
I have seen the following bug with the xmlnsc parser, which caused me to stop using it in favor of xmlns until it matures a bit:
if an element evaluates to "null", then it seems to be populating with the previous sibling's value rather than the value "null". |
This is a known defect. and there is a fix available. |
|
| Back to top |
|
|
| TinTin |
| Posted: Mon Mar 26, 2007 3:05 pm Post subject: |
|
|
Newbie
Joined: 26 Mar 2007
Posts: 2
|
On a related subject.
| Quote: |
| Code: |
IF FIELDTYPE(theElement) = NameValue THEN set new field equal to this one.
ELSEIF FIELDTYPE(theElement) = Name THEN set new field = NULL or spaces. |
If it has a fieldtype of Name, then it evaluates to NULL, but if you do try and set the new field to it, you are going to get unpredictable results - either whitespace elements, or something else.quote] |
I assume that the NameValue test refers to an XML attribute value being present and that the Name test refers to an XML element value being present? If so, would an alternative be something like:
| Code: |
IF FIELDTYPE(theElement) = XMLNC.Attribute THEN set new field equal to this one.
ELSEIF FIELDTYPE(theElement) NOT IN (XML.Field, XML.Folder) THEN set new field = NULL or spaces |
OR
| Code: |
IF FIELDTYPE(theElement) = XMLNC.Attribute THEN set new field equal to this one.
ELSEIF theElement IS NULL -- (no tag) THEN set new field = NULL or spaces
ELSEIF theElement = '' -- (no value) THEN set new field = NULL or spaces |
Perhaps I've missed something? Sorry in advance for any misunderstanding on my part (although I have read the FIELDTYPE page in the manual). |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Tue Mar 27, 2007 6:23 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
| TinTin wrote: |
On a related subject.
| Quote: |
| Code: |
IF FIELDTYPE(theElement) = NameValue THEN set new field equal to this one.
ELSEIF FIELDTYPE(theElement) = Name THEN set new field = NULL or spaces. |
If it has a fieldtype of Name, then it evaluates to NULL, but if you do try and set the new field to it, you are going to get unpredictable results - either whitespace elements, or something else.quote] |
I assume that the NameValue test refers to an XML attribute value being present and that the Name test refers to an XML element value being present? If so, would an alternative be something like:
| Code: |
IF FIELDTYPE(theElement) = XMLNC.Attribute THEN set new field equal to this one.
ELSEIF FIELDTYPE(theElement) NOT IN (XML.Field, XML.Folder) THEN set new field = NULL or spaces |
OR
| Code: |
IF FIELDTYPE(theElement) = XMLNC.Attribute THEN set new field equal to this one.
ELSEIF theElement IS NULL -- (no tag) THEN set new field = NULL or spaces
ELSEIF theElement = '' -- (no value) THEN set new field = NULL or spaces |
Perhaps I've missed something? Sorry in advance for any misunderstanding on my part (although I have read the FIELDTYPE page in the manual). |
NameValue indicates an element with a value. Name indicates an element without a value (=NULL). Any element that evaluates to null, the XMLNSC had/does consider to be a "folder." I had tried with using the XMLNSC.Attribute or XMLNSC.Element, but those didnt work for some reason. Anyway, this was just a quick work around. There is a fix available, so I would use that.
| kimbert wrote: |
| This is a defect in the XMLNSC parser. If you raise a PMR you can get an IFix for this. You should ask for a test fix for PMR 12211,999,866. |
|
|
| Back to top |
|
|
| TinTin |
| Posted: Tue Mar 27, 2007 12:59 pm Post subject: |
|
|
Newbie
Joined: 26 Mar 2007
Posts: 2
|
| Quote: |
| I had tried with using the XMLNSC.Attribute or XMLNSC.Element, but those didnt work for some reason. Anyway, this was just a quick work around. There is a fix available, so I would use that |
Thanks very much for the info. I assume 'test fix for PMR 12211,999,866' is the stage prior to an official PTF.
From my tests I can confirm that any operations evaluating on any of the XMLNSC constants will not work:
| Code: |
| IF xmlref= XMLNSC.*; |
However, worth noting that operations like the following work ok:
| Code: |
| SET var = CARDINALITY (xmlRef.(XMLNSC.Folder)*[]); |
There is no XMLNSC.Element constant. Instead there are XMLNSC.Field and XMLNSC.Folder constants. |
|
| Back to top |
|
|
| Marek |
| Posted: Wed Mar 28, 2007 6:51 am Post subject: |
|
|
Apprentice
Joined: 30 Jun 2004
Posts: 32
Location: Edinburgh
|
For the record and using XML.Attribute as an example:
XML.Attribute should = '0x03000100'.
However, the bug is that XML.Attribute actually = '0xFF03000100'.
So I've temporarily hard coded an ELSEIF in my logic to overcome the issue until I get a fix.
| Code: |
IF FIELDTYPE(p_xmlTree) = XMLNSC.Attribute THEN
SET keyArray.Row[index].key = p_xmlTree.(XMLNSC.Attribute)key;
ELSEIF FIELDTYPE(p_xmlTree)= '0x03000100' THEN
SET keyArray.Row[index].key = p_xmlTree.(XMLNSC.Attribute)key;
... |
|
|
| Back to top |
|
|
| Marek |
| Posted: Wed Mar 28, 2007 6:59 am Post subject: |
|
|
Apprentice
Joined: 30 Jun 2004
Posts: 32
Location: Edinburgh
|
| Quote: |
XML.Attribute should = '0x03000100'.
However, the bug is that XML.Attribute actually = '0xFF03000100'. |
Sorry ... XML.Attribute should read XMLNSC.Attribute |
|
| Back to top |
|
|
|
|
