| Author |
Message
|
| goffinf |
 Posted: Fri Mar 03, 2006 9:28 am Post subject: XMLNSC mixed content question |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Message Broker v6
Parser: XMLNSC
Given the XML snippet (below), I have a piece of eSQL (also below) that iterates through the simpleHeaders child nodes getting their name, value and the value of an attribute.
However, the when the node is empty as for 'foo' and 'bar' the headerValue does not contain NULL as I was expecting, but instead contains /n/t/t/t/t/t which appears to indicate that it is picking up the new-line and several tab characters between the end of the node and the start of the next. What I want to get is NULL.
The compute node settings on the XMLNSC Parser Options tab are :-
Mixed Content Retain Mode: None
Comments Retain Mode : None
Processing Instructions Retain Mode : None
I had assumed that the first of these would have stopped this behaviour, that is, ignore mixed content, but apparently not ?
Can anyone advise as to what I'm doing wrong here ??
(note: I have used 'origin' below as generic placeholder for the location in the message tree that I am processing from) :-
SET I = 1;
SET J = CARDINALITY(origin.response.simpleHeaders.*[]);
WHILE I <= J DO
SET headerName = FIELDNAME(origin.response.simpleHeaders.[I]);
SET headerValue = origin.response.simpleHeaders.[I];
SET required = origin.response.simpleHeaders.[I].required;
... do other stuff
SET I = I + 1;
END WHILE;
XML snippett :-
<response>
<simpleHeaders>
<foo required="true"/>
<bar required="true"/>
... |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Mar 03, 2006 9:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You could always read the data as BLOB and strip out any such whitespace, and then parse it as XML.
Or you could be a little more selective about what types of children you look for underneath simpleHeaders.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Mar 03, 2006 11:00 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| jefflowrey wrote: |
You could always read the data as BLOB and strip out any such whitespace, and then parse it as XML.
Or you could be a little more selective about what types of children you look for underneath simpleHeaders. |
wouldn't that give you:
<response>
<simpleHeaders>
<foorequired="true"/>
<barrequired="true"/>
_________________
-wayne |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Mar 03, 2006 11:03 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
Tried a couple of different approaches but no joy. I found that depending on what TYPE you use when performing the MOVE the positioning of the cursor differ. Obvious perhaps, but still some unexpected behaviour (at least to my novice mind  . Any ideas :-
DECLARE header REFERENCE TO Environment.Lookup.{flowName}.response.simpleHeaders;
-- this will land on any field that DOES have a value
MOVE header FIRSTCHILD TYPE XMLNSC.Field;
-- this only lands on fields that DONT have a value ??
-- MOVE header FIRSTCHILD TYPE 0x01000000;
-- I think this was the same as for 0x01000000;
--MOVE header FIRSTCHILD TYPE XMLNSC.Folder;
WHILE LASTMOVE(header) DO
SET headerName = FIELDNAME(header);
SET headerValue = FIELDVALUE(header);
SET required = header.required;
... do stuff
MOVE header NEXTSIBLING REPEAT TYPE;
END WHILE;
XML being processed :-
<response>
<simpleHeaders>
<GUID required="true"/> </GUID>
<CallerHeader_ApplicationUserName required="true"> </CallerHeader_ApplicationUserName>
<CallerHeader_ApplicationUserID required="true">aviva</CallerHeader_ApplicationUserID>
<RootLevel_SequenceNumber required="true"> </RootLevel_SequenceNumber>
<foo required="false"/>
<!--<bar required="true"/>-->
<baz required="true">abc</baz>
</simpleHeaders> |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Mar 03, 2006 11:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Wayne - It depends on what I meant by "any such whitespace", doesn't it?
goffinf - you're on the right track with TYPE, I think. The problem that will arise is, suppose you have xml that looks exactly like "<simpleHeaders>\t\n\n\n</simpleHeaders>". The XML parser will always create simpleHeaders as having at least one child. It will never create it in such a way that it can logically treat simpleHeaders as a NULL value.
You can maybe use a cardinality and a select to find out how many NAME children that simpleHeaders has. The "\t\n\n\n" should be a NAMEVALUE child, not a NAME child.
Also, what is the XMLNSC parser? I'm only aware of XML, and XMLNS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Mar 03, 2006 12:04 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
XMLNSC:
| Quote: |
The XMLNSC domain is an extension of the XMLNS domain, which in turn, was an extension of the original XML domain.
The intent with the XMLNS domain was to add namespace support and, for compatibility reasons, a new domain was created so that existing applications would not be affected. The intent with the new XMLNSC domain is to build a more compact tree and, therefore, use less memory when handling large messages. Again, for compatibility reasons, a new domain has been added so that existing applications are not affected.
|
_________________
-wayne |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Mar 03, 2006 12:07 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
The XMLNSC parser is the 'compact' XML parser that comes with MB v6. It is a bit different from what we were used to with v5 (XMLNS). Below is an exert from help that explains what it is.
I want to be able to 'touch' every node in the list below simpleHeaders regardless of whether they have content or not (because I want to do something specific if they don't). It will never be the case that the node content itself would contain /n/t/t/t/t etc.. I'm sure this is the mixed content BETWEEN the elements.
This parser is mucho frustrating at times !
Regards
Fraser.
The XMLNSC domain is an extension of the XMLNS domain, which in turn, was an extension of the original XML domain.
The intent with the XMLNS domain was to add namespace support and for compatibility reasons, a new domain was created so that existing applications would not be affected. The intent with the new XMLNSC domain is to build a more compact tree and, therefore, use less memory when handling large messages. Again, for compatibility reasons, a new domain has been added so that existing applications are not affected.
Message tree structure
The XMLNSC parser obtains its more compact tree by using a single name-value element to represent tagged text, rather than the separate name and value elements used by the XML and XMLNS parsers. |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri Mar 03, 2006 1:22 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
If I test for FIELDTYPE of Name and NameValue I can sort of get what I need :-
CASE TRUE
WHEN FIELDTYPE(origin.response.simpleHeaders.[I]) = Name THEN
SET headerValue = NULL;
WHEN FIELDTYPE(origin.response.simpleHeaders.[I]) = NameValue THEN
SET headerValue = origin.response.simpleHeaders.[I];
...
Fraser. |
|
| Back to top |
|
|
| SixBlade |
| Posted: Mon Mar 06, 2006 3:26 am Post subject: |
|
|
Apprentice
Joined: 03 Dec 2003
Posts: 26
Location: UK
|
Does it help if you try to tell what you expect:
ie instead of "set headerValue = origin.response.simpleHeaders.[i]"
use "set headerValue = origin.response.simpleHeaders.(XMLNSC.Value)[i]"
That should not get the whitespace characters.
There's also (XMLNSC.Folder for headerName and XMLNSC.Attrribute) for required) |
|
| Back to top |
|
|
| SixBlade |
| Posted: Mon Mar 06, 2006 4:58 am Post subject: |
|
|
Apprentice
Joined: 03 Dec 2003
Posts: 26
Location: UK
|
Sometimes when you type stuff it takes a while to realize it probably wasn't the right sequence of characters...
It should NOT be XMLNSC.Value, that will get whitespace as well...I was thinking of XMLNSC.PCDataValue, but won't work either, the tags are of different types.
Empty tags (or tags containg other tags) are XLNSC.Folder, the ones that do contain PCDATA appear as XMLNSC.Field in a Trace. So a check is probably needed (specifying XMLNSC.Field on target node which is XMLNSC.Folder does not create desired result). |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Mar 06, 2006 7:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| The compute node settings on the XMLNSC Parser Options tab are... |
I would be more interested to see the setttings on your MQInput node. Unless you're triggering the parse via ESQL ( CREATE FIELD...PARSE ) the MQInput node properties will be the ones affecting the parsing of the document. Having said that, the default behaviour of XMLNSC is to discard mixed content, so I would also check that your MQInput node has specified the correct parser. If you're still having problems, put a trace node just before the Compute node, set the pattern to ${Root}, and post the relevant section of the output here. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Feb 02, 2007 1:44 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| This is a defect in XMLNSC. 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 |
|
|
|
|
