| Author |
Message
|
| special_agent_Queue |
 Posted: Fri Oct 20, 2006 6:33 am Post subject: XMLNSC parser working incorrectly? |
 |
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
My understanding is that the XMLNSC parser REMOVES the XML.Whitespace elements which were left by previous versions of the xml parsers.
However, in my output message, I am finding these whitespace elements. They are placed in as values of fields (so that ........ shows as the value of the field) when the input message has these fields as null.
Please see my sample input and output as well as the piece of code creating the output in order to get a better explaination of the problem. Is there anyway to work around this? Or am I just making a silly error?
Sample input:
| Quote: |
<clm:AttorneyRole>
<clm:Attorney>
<ptyimpl:IndividualImpl pid="P001" refid="KG001">
<impl:effectiveDate>2006-09-11</impl:effectiveDate>
<impl:processDate>2006-09-10</impl:processDate>
<impl:KeyGroup id="K001" keyGroupType="Company" refid="KG001">
<AlternateId state="exists" value="0001" sourceLogicalId="AB"/>
</impl:KeyGroup>
<ptyimpl:Individual PID="P00">
<pty:KeyGroup id="K008" keyGroupType="Company" refid="KG001">
<AlternateId state="exists" value="0001" sourceLogicalId="AB"/>
<UUID/>
</pty:KeyGroup>
<pty:ContactPointUsages>
<pty:ContactPointUsage contactPointID="CP004">
<loc:use>Professional</loc:use>
<loc:availability/>
<loc:preferredTime/>
<loc:fromMonth/>
<loc:fromDay/>
<loc:toMonth/>
<loc:toDay/>
<loc:Email contactPointID="CP004">
<loc:location/>
</loc:Email>
</pty:ContactPointUsage>
</pty:ContactPointUsages>
<pty:title/>
<pty:firstName/>
<pty:middleName/>
<pty:lastName/>
<pty:suffix/>
<pty:comments/>
</ptyimpl:Individual>
</ptyimpl:IndividualImpl>
</clm:Attorney>
</clm:AttorneyRole> |
Code piece with problem:
| Code: |
| CREATE NEXTSIBLING OF NewPointer DOMAIN('XMLNSC') NAME EvalFname VALUE FIELDVALUE(Pointer); |
Output piece:
| Quote: |
<corrToIndividualImpl>
<corrToeffectiveDate>2006-09-11</corrToeffectiveDate>
<corrToprocessDate>2006-09-10</corrToprocessDate>
<corrToKeyGroup>
<corrToAlternateId>.........</corrToAlternateId>
</corrToKeyGroup>
<corrToIndividual>
<corrToKeyGroup></corrToKeyGroup>
<corrToContactPointUsages>
<corrToContactPointUsage>
<corrTouse>Professional</corrTouse>
<corrToavailability>...........</corrToavailability>
<corrTopreferredTime>...........</corrTopreferredTime>
<corrTofromMonth>...........</corrTofromMonth>
<corrTofromDay>...........</corrTofromDay>
<corrTotoMonth>...........</corrTotoMonth>
<corrTotoDay>...........</corrTotoDay>
<corrToEmail>
<corrTolocation>............</corrTolocation>
</corrToEmail>
</corrToContactPointUsage>
</corrToContactPointUsages>
<corrTotitle>.......................................</corrTotitle>
<corrTofirstName>.........</corrTofirstName>
<corrTomiddleName>.........</corrTomiddleName>
<corrTolastName>.........</corrTolastName>
<corrTosuffix>.........</corrTosuffix>
<corrTocomments>.........</corrTocomments>
</corrToIndividual>
</corrToIndividualImpl> |
I've even tried putting in an If statement to test the field value so that if it is null, then I'd write out a null valued field. However, the test was never successful, and always reproduced the above output.
Thanks for the help. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Oct 20, 2006 7:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I don't think XMLNSC is supposed to remove whitespace INSIDE elements, just AROUND elements.
So it wouldn't clean up "<b>...</b><a>........</a>" and turn it into "<b></b><a></a>", but it would turn "<b>...</b>......|lf|.....<a>.....</a>" into "<b>...</b><a>.....</a>".
I suspect your problem is that you're doing something weird with CREATE and references when you probably just want to use SET.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 20, 2006 8:16 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Jeff is correct. XMLNSC removes mixed content ( whitespace AND TEXT which occurs in between elements ). It does not remove whitespace which occurs between the start and end tag of an element. Nor does it remove whitespace within the value of an attribute. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Fri Oct 20, 2006 8:33 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
If I were to use set, wouldn't it create the field as the last child or the preceding parent?
I didn't think it was supposed to remove whitespace in elements, however, when an element comes in like <someElement/> (which doesn't have anything between the opening and closing tags), and then I add a prefix to it and use the same value, wouldn't it result in
<someElement/>
<prefixsomeElement/>
?
And then I'd delete the original element.
Instead, I am getting
<someElement/>
<prefixsomeElement>.........</prefixsomeElement>
I have to add prefixes because the product we are communicating with doesn't fully support XML.
When it creates the Xpath, it only does it for the child and one parent, or something like that, so it cannot handle anything like
<to>
<field1>
<field1child/>
</field1>
</to>
<from>
<field1>
<field1child/>
</field1>
</from>
In this case, it will only read the information from the from section.
jefflowrey, do you have any idea with what that something weird with CREATE and references is?
I appreciate all the help. Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 20, 2006 8:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess I don't know what is causing your problem. But a couple of thoughts.
One, you don't need to specify the parser on a create field unless, umm, you need to. If you're inserting into a tree somewhere down below a properly created OutputRoot.XMLNSC element, it's at best a waste of typing to specify the create field.
Secondly, you should look at what FIELDVALUE returns if you're passing it an element with a NULL field value - which a tag like <a/> would generate.
Thirdly, again unless you are trying to insert an element into a specific location, I would use SET instead of CREATE FIELD. Even if you need to create a subtree rooted at the specific location, I would only use Create to build the first element, and then use SET to build everything else below that.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Fri Oct 20, 2006 10:24 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
Thanks for your response.
As to your suggestions:
1) I removed the DOMAIN clause. Nothing changed.
2) I set a variable and stepped through a number of iterations on the debugger. When a value came in, it displayed that. When the field was null, it looked blank.
3) I cannot switch to SET, because I need to use a variable to represent the field name as well, because it is in a loop and the prefix could change, as well as the original field name. I don't think SET would work with that. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 20, 2006 10:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Set works just fine with {variableName}.
In the debugger, the field looks BLANK, or does it hold a "NULL" value?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Fri Oct 20, 2006 11:05 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
I switched to set with the {variableName}.
I am still getting those ... (carriage returns) in the value or the new fields.
In the debugger, the variable I set = FIELDVALUE(Pointer) has an = and the value of the field when it should have a value.
When the input field is NULL, there is no = nor value displayed next to the variable, and I am unable to double click on it/change the value of it in the debugger. However, when there is a value, I am able to do both of those things. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Oct 23, 2006 1:30 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
From http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ad02430_.htm
| Quote: |
| The primary purpose of the operator IS is to test whether a value is NULL. The comparison operator (=) does not allow this because the result of comparing anything with NULL is NULL. |
The problem is that you are copying a non-existent value. You need something like this ( not tested ) :
| Code: |
IF (Pointer IS NOT NULL)
SET <path> = FIELDVALUE(Pointer);
ELSE
SET <path> VALUE = NULL;
ENDIF;
|
| Quote: |
| I've even tried putting in an If statement to test the field value so that if it is null |
You probably used a statement which included FIELDVALUE, which would not work for the reasons stated above. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 23, 2006 2:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you don't know the value being allocated to the field but want the field to show up in the tree regardless the easiest way is:
| Code: |
| SET ref.nsprefix:fieldname VALUE = whatevervalueincludingnull; |
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Tue Oct 24, 2006 7:10 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
Thanks fjb_saper and kimbert. However, neither of those solve the problem.
I found this previous post which describes my problem as well. I must have been searching for the wrong terms before.
http://www.mqseries.net/phpBB2/viewtopic.php?t=27765&highlight=
I'll have to test the testing for the fieldtype rather than the fieldvalue.
Any other solutions? |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Oct 24, 2006 7:21 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| OK - that's unexpected. Thanks for the feedback. I'll take a look sometime and see what's going on. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Thu Nov 02, 2006 6:12 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
| The case statement to test for fieldtype equaling Name or NameValue definitely works. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Feb 02, 2007 1:46 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| 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 |
|
|
|
|
