| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Need help on namespace declaration |
« View previous topic :: View next topic » |
| Author |
Message
|
| WBI_user |
 Posted: Wed Jul 07, 2004 9:51 am Post subject: Need help on namespace declaration |
 |
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
I need to produce the namespace info as follow:
<?xml version="1.0"?>
<Mymsg xmlns= "http://www.abc.com/TE/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.abc.com/TE/ItemMsg.xsd" Version="1.0">
<data1>1234567ab</data1>
</Mymsg>
The esql I use is:
DECLARE xmlns NAMESPACE 'http://www.abc.com/TE/';
DECLARE xsi NAMESPACE 'http://www.w3.org/2001/XMLSchema-instance';
SET OutputRoot.XMLNS.(XML.XmlDecl).(XML.Version)='1.0 ';
SET OutputRoot.XMLNS.Mymsg.(XML.NamespaceDecl)xmlns='http://www.abc.com/TE/' ;
SET OutputRoot.XMLNS.Mymsg.(XML.NamespaceDecl)xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' ;
SET OutputRoot.XMLNS.Mymsg.(XML.NamespaceDecl)xsi:schemaLocation='http://www.abc.com/TE/integration/ItemMsg.xsd' ;
SET OutputRoot.XMLNS.Mymsg.(XML.NamespaceDecl) Version='1.0';
SET OutputRoot.XMLNS.Mymsg.data1 = '1234567ab';
My output looks like:
<?xml version="1.0 "?>
<Mymsg xmlns="" xmlns="http://www.abc.com/TE/" xmlns:NS1="http://www.abc.com/TE/" NS1:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:NS2="http://www.w3.org/2001/XMLSchema-instance" NS2:schemaLocation="http://www.abc.com/TE/ItemMsg.xsd" Version="1.0">
<data1>1234567ab</data1>
</Mymsg>
I don't understand why I am getting the extra xmlns="" and why it inserts the NS1 and NS2 for me.
Can anyone point out what I did worng and how I can produce what I want.
I am using WBI MB V5 CSD2 on Windows 2000. |
|
| Back to top |
|
 |
| Hari |
| Posted: Wed Jul 07, 2004 10:06 am Post subject: |
|
|
Centurion
Joined: 21 Nov 2002
Posts: 117
Location: USA
|
|
| Back to top |
|
|
| TonyD |
| Posted: Wed Jul 07, 2004 8:40 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
Re the extra "xmlns".... we came acrross this one earlier this year....see below responses from IBM:
| Quote: |
We discussed this subject PMR issue with our Change Team and have
the following update from them:
=========================================================
It would appear that the customer has found a defect in the product.
If the following ESQL is written : Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
                                    Â
SET OutputRoot.XMLNS.CustomerSearchRequest.(XML.NamespaceDecl)xmlns = Â Â
 'http://abc.com/scv/customersearchrequest-1/2004/01';         Â
SET OutputRoot.XMLNS.CustomerSearchRequest.Body.SearchCriteria = Â Â Â Â
 'String';                               Â
                                    Â
Then the user is attempting to define a default namespace in the XML Â Â
output message. However, as you have found, this writes the following: Â
                                    Â
 <CustomerSearchRequest xmlns=""                    Â
    xmlns="http://abc.com/scv/customersearchrequest-1/2004/01">   Â
  <Body>                               Â
   <SearchCriteria>String</SearchCriteria>              Â
  </Body>                               Â
 </CustomerSearchRequest>                       Â
                                   Â
... writing an empty namespace declaration, as well as the proper   Â
default one that was requested. Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
                                   Â
This only appears to occur if an attempt is made to write a default  Â
namespace. If the a labelled namespace declaration is added such as  Â
with                                 Â
                                   Â
SET OutputRoot.XMLNS.CustomerSearchRequest.(XML.NamespaceDecl) Â Â Â Â
 xmlns:schreq='http://abc.com/scv/customersearchrequest-1/2004/01'; Â
SET OutputRoot.XMLNS.CustomerSearchRequest.Body.SearchCriteria = Â Â Â
 'String';                              Â
                                   Â
Then the output is : Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
                                   Â
<CustomerSearchRequest                        Â
 xmlns:schreq="http://abc.com/scv/customersearchrequest-1/2004/01">  Â
 <Body>                                Â
  <SearchCriteria>String</SearchCriteria>               Â
 </Body>                               Â
 </CustomerSearchRequest>                       Â
                                   Â
 Which does not have the empty xmlns declaration in it.                Â
==============================================================
.
We have raised an APAR Â IC39599 Â along the lines of :
Empty namespace when  setting default namespace in XMLNS |
We have used the following workaround suggested by IBM, pending the fix which was just too late for FP3 and will therefore be in FP4:
| Quote: |
The user can workaround the problem by converting the XMLNS
message to the BLOB domain and then removing the hex bytes that
represent the characters xmlns="". So for example :
-- First create a simple xmlns tree that will cause the bug
SET OutputRoot.XMLNS.CustomerSearchRequest.(XML.NamespaceDecl)xmlns=
'http://abc.com/scv/customersearchrequest-1/2004/01';
SET OutputRoot.XMLNS.CustomerSearchRequest.Body.SearchCriteria =
'String';
-- Now we implement the four lines of workaround.
DECLARE msgBlob BLOB ASBITSTREAM(OutputRoot.XMLNS,
OutputRoot.MQMD.Encoding,
OutputRoot.MQMD.CodedCharSetId);
DECLARE xmlnsBlob BLOB CAST('xmlns=""' AS BLOB
CCSID OutputRoot.MQMD.CodedCharSetId);
SET OutputRoot.XMLNS = NULL;
SET OutputRoot."BLOB"."BLOB" = REPLACE(msgBlob, xmlnsBlob);
-- End the workaround.
Note : Formatted for RETAIN purposes.
The first line of this workaround ESQL uses the ASBITSTREAM function
to create a bitstream of the XMLNS message tree. This will not add
any performance overhead to the flow, because an MQOutput node
would have to do this task anyway. We then create a BLOB in the
codepage we are dealing with that represents the text that needs
to be removed. The XMLNS folder is then deleted, and then an
output BLOB folder is created that has had the erroneous xmlns=""
text removed which was done by the ESQL REPLACE function.
In this example, this four line workaround has been placed in the
same compute node in which the XMLNS message tree was created.
However, the user may wish to manipulate this tree further in the
flow, so if this is the case, this ESQL should be placed in the
last compute node before the output node. |
|
|
| Back to top |
|
|
| WBI_user |
| Posted: Fri Jul 09, 2004 6:48 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
Thanks for the update, the removal of the extra xmlns=" " works fine. I have a question regarding the NS1 generated by the XMLNS parser. In the entry pointed to by the URL in the previous reply, it says that to have a prefix of our choice, we need to use MRM. Does it mean that I have to have my output XML message in MRM ? I am a little confused. I am generating my xml output by using
SET OutputRoot.XMLNS..... and the example quoted in that entry is
SET OutputRoot.MRM.err:Error.err:Level = 'FATAL';
It seems that I am using two parsers for output. Is that right ? Can some one help me to understand this ? |
|
| Back to top |
|
|
| TonyD |
| Posted: Sun Jul 11, 2004 3:01 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
No, MRM is not required for you to set your prefix...the other example addressed a different issue.
You can use either the MRM or XMLNS (but not the XML) domains for messages that reference namespaces. If you use MRM you must create a message definition file from the schema.
XMLNS is simply an extension of the XML domain and requires no message definition.
A couple of suggestions re the message you are trying to build:
1. Remove the 'DECLARE xmlns NAMESPACE 'http://www.abc.com/TE/' line.
2. Alter 'XML.NamespaceDecl' to 'XML.Attribute' for 'xsi:schemaLocation' and 'Version'. |
|
| Back to top |
|
|
| TonyD |
| Posted: Thu Jul 15, 2004 3:12 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
Subsequent to my initial post to this thread, re 'xmlns=""', IBM have now determined that this is not a bug but a matter of usage. Essentially, when building a message that has namespaces enabled all elements must be namespace-qualified including those belonging to the default namespace.
The SET commands in the example above ('SET OutputRoot.XMLNS.MyMsg......') are therefore parsed as belonging to namespace '''' (empty), and an appropriate namespace declaration is generated i.e. 'xmlns=""'.
The correct way to code the example would therefore appear to be:
| Code: |
DECLARE TE NAMESPACE 'http://www.abc.com/TE/';
DECLARE xsi NAMESPACE 'http://www.w3.org/2001/XMLSchema-instance';
SET OutputRoot.XMLNS.(XML.XmlDecl).(XML.Version)='1.0 ';
SET OutputRoot.XMLNS.TE:Mymsg.(XML.NamespaceDecl)xmlns = 'http://www.abc.com/TE/';
SET OutputRoot.XMLNS.TE:Mymsg.(XML.NamespaceDecl)xmlns:xsi = 'http://www.w3.org/2001/XMLSchema-instance';
SET OutputRoot.XMLNS.TE:Mymsg.(XML.Attribute)xsi:schemaLocation = 'http://www.abc.com/TE/integration/ItemMsg.xsd';
SET OutputRoot.XMLNS.TE:Mymsg.(XML.Attribute)Version='1.0';
SET OutputRoot.XMLNS.TE:Mymsg.TE:data1 = '1234567ab'; |
This produces the following XML:
| Code: |
<?xml version="1.0 "?>
<Mymsg xmlns="http://www.abc.com/TE/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.abc.com/TE/integration/ItemMsg.xsd" Version="1.0">
<data1>1234567ab</data1>
</Mymsg>
|
I am happy to email the more detailed explanation from IBM to anyone who is interested, or on this thread if people think it would be useful. |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Jul 15, 2004 3:37 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Tony,
It'd be good if you could post it here.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| TonyD |
| Posted: Thu Jul 15, 2004 6:48 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
As noted above, also experienced by the originator of this thread, we encountered a situation earlier this year where, when building an XML message that included elements belong to a default namespace, we found that WBIMB generated an 'xmlns=""' declaration in addition to our default namespace declaration. We therefore placed a software support call.
The following is the message I received from development yesterday, which revised their original assessment that it was a defect (I highlighted the bold section):
****************************************************************
Whilst attempting to identify a fix to this APAR it has only just become apparent that this is not the defect we thought it was.
For this problem the customer reported that an extra xmlns="" is written in the output message which makes it an invalid xml message.
We have found the cause of why this extra namespace declaration is written out and it occurs when a contradiction is found in the message tree. In this case, the contradiction is that the user has forcibly defined a default namespace declaration in the message tree, but has also specified elements in the XMLNS message tree that do not have namespaces associated with them.
When this contradictory set of conditions occur, then XMLNS writer attempts to blank out the existing default namespace that is in scope. Currently an attempt is made to do this, but accidentally adds a blank namespace to the namespace list for this message. This is why an extra blank namespace declaration appears in the output message.
After discussing this with the development team, it seems that even if this default namespace had been blanked out correctly, this still would not have been the correct behaviour. When these contradictory conditions occur in the message tree then the XMLNS writer should throw an exception to indicate that these conditions have occured.
So if we were supply a fix to this problem, it probably would not be the fix the customer is expecting, ie, the customer would most likely expect the message flow to write a valid XML message for their ESQL. However, we would actually throw an exception when processing the message tree they have constructed.
So far in this description we have discussed contradictory set of conditions. The customers ESQL creates a message tree that has a default name space, but has created elements that are not in namespaces, as follows :
| Code: |
SET OutputRoot.XMLNS.CustomerSearchRequest.(XML.NamespaceDecl)xmlns =
'http://xyz.com/scv/customersearchrequest-1/2004/01';
SET OutputRoot.XMLNS.CustomerSearchRequest.Body.SearchCriteria = 'String';
|
In the resultant message tree, the fields CustomerSearchRequest, Body and SearchCriteria have not been defined with a namespace.
Unfortunately ESQL message trees do not work in the same way that XML parsing does. Creating a default namespace in the message tree does not imply that all fields created in its scope without a namespace will be given this namespace. If the customer wants these elements in the default namespace then they need to specify the default namespace on the field when it is created.
The user may think it would be helpful if the default namespace would get passed to the elements without the namespace, however, this would mean that a round trip consistent parse would not be possible.
What we mean by this is the following :
If the following XML message is parsed :
| Code: |
<CustomerSearchRequest xmlns="http://xyz.com/scv/customersearchrequest-1/2004/01">
<Body>
<SearchCriteria>String</SearchCriteria>
</Body>
</CustomerSearchRequest>
|
Then the following tree would be produced :
| Code: |
(0x01000010):XMLNS = (
(0x01000000)http://xyz.com/scv/customersearchrequest-1/2004/01:CustomerSearchRequest = (
(0x07000012):xmlns
= 'http://xyz.com/scv/customersearchrequest-1/2004/01'
(0x01000000)http://xyz.com/scv/customersearchrequest-1/2004/01:
Body = (
(0x01000000)http://xyz.com/scv/customersearchrequest-1/2004/01:
SearchCriteria = (
(0x02000000): = 'String'
)
)
)
)
|
As can be seen, the default namespace has been given to those fields in the message tree (within its scope) that did not have a namespace.
In the customers writing scenario they have produced the following message tree :
| Code: |
(0x01000010):XMLNS = (
(0x01000000)CustomerSearchRequest = (
(0x07000012):xmlns
= 'http://xyz.com/scv/customersearchrequest-1/2004/01'
(0x01000000)Body = (
(0x01000000)SearchCriteria = (
(0x02000000): = 'String'
)
)
)
)
|
Which they want to produce the same output message as shown above. But then that would mean that two different message trees would produce the same output message, and hence the round trip scenario would not be consistent. Ie, if we reparsed this output message we would not get the same message tree that produced the message.
This is why we should be throwing an exception when a default namespace has been specified, but fields have not been included in a namespace.
If the customer is manually adding a default namespace in the output XMLNS message tree, then they need to ensure that fields are added to this default namespace explicitly.
The APAR will be used to implement the throwing of the exception in this scenario.
**************************************************************** |
|
| 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
|
|
|
|
