ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XMLNSC Declare Reference bug? Navigate XML Tree 6.0.2

Post new topic  Reply to topic
 XMLNSC Declare Reference bug? Navigate XML Tree 6.0.2 « View previous topic :: View next topic » 
Author Message
Marek
PostPosted: Mon Mar 26, 2007 6:10 am    Post subject: XMLNSC Declare Reference bug? Navigate XML Tree 6.0.2 Reply with quote

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
View user's profile Send private message
special_agent_Queue
PostPosted: Mon Mar 26, 2007 6:26 am    Post subject: Reply with quote

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
View user's profile Send private message
msukup
PostPosted: Mon Mar 26, 2007 7:24 am    Post subject: Reply with quote

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
View user's profile Send private message MSN Messenger
elvis_gn
PostPosted: Mon Mar 26, 2007 7:36 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Marek
PostPosted: Mon Mar 26, 2007 7:37 am    Post subject: Reply with quote

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
View user's profile Send private message
Marek
PostPosted: Mon Mar 26, 2007 8:22 am    Post subject: Reply with quote

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
View user's profile Send private message
special_agent_Queue
PostPosted: Mon Mar 26, 2007 9:11 am    Post subject: Reply with quote

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
View user's profile Send private message
special_agent_Queue
PostPosted: Mon Mar 26, 2007 9:15 am    Post subject: Reply with quote

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
View user's profile Send private message
msukup
PostPosted: Mon Mar 26, 2007 1:07 pm    Post subject: Reply with quote

Acolyte

Joined: 11 Feb 2002
Posts: 56

thanks, special agent! I'll make sure to use this workaround.
Back to top
View user's profile Send private message MSN Messenger
kimbert
PostPosted: Mon Mar 26, 2007 2:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
TinTin
PostPosted: Mon Mar 26, 2007 3:05 pm    Post subject: Reply with quote

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
View user's profile Send private message
special_agent_Queue
PostPosted: Tue Mar 27, 2007 6:23 am    Post subject: Reply with quote

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
View user's profile Send private message
TinTin
PostPosted: Tue Mar 27, 2007 12:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
Marek
PostPosted: Wed Mar 28, 2007 6:51 am    Post subject: Reply with quote

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
View user's profile Send private message
Marek
PostPosted: Wed Mar 28, 2007 6:59 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XMLNSC Declare Reference bug? Navigate XML Tree 6.0.2
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.