MQSeries.net :: View topic - NameValue+ vs Name+/Value+

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » NameValue+ vs Name+/Value+

NameValue+ vs Name+/Value+

« View previous topic :: View next topic »

Author

Message

Herbert

Posted: Wed May 26, 2010 2:18 am Post subject: NameValue+ vs Name+/Value+

Centurion

Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands

Hi,

Below a snippet from a trace node:

Code:

(0x0300000B:NameValue+)http://www.xxx.com/dds:Dat01 = TIMESTAMP '2010-04-28 14:06:49' (TIMESTAMP)

(0x01000013:Name+ )http://www.xxx.com/dds:Dat02 = (
(0x0200000B:Value+): = TIMESTAMP '2010-12-31 00:00:00' (TIMESTAMP)
)

Wat is the difference between those 2 fields?

I have troubles to retrieve the value of the second one in ESQL.

Just adding a extra level .*:*. is not working. Or using FIELDVALUE is also not working.

Kind Regards, Herbert

mqjeff

Posted: Wed May 26, 2010 2:26 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

I think you need to look up the meaning of 0x0200000B as a parser-specific type.

For example, if that's an XMLNSC tree, then (and I'm not saying it *is*, I've not done the lookup and I didn't write the XMLNSC parser so I don't have these things memorized.... ) 0x020000B could be an XMLNSC.Attribute, and so you would need to use (XMLNSC.Attribute) to reference it properly in ESQL.

fjb_saper

Posted: Wed May 26, 2010 2:29 am Post subject: Re: NameValue+ vs Name+/Value+

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Herbert wrote:

Hi,

Below a snippet from a trace node:

Code:

Could it be that in the first example you have
<ns:Dat01 type=timestamp>2010-04-28 14:06:49</ns:Dat01>
Where the second would represent something like
<element name="http://www.xxx.com/dds:Dat02 = " value="2010-12-31 00:00:00" />
But then this is just a guess.
For more details check out the significance of the types 0x01000013 and 0x0200000B, 0x0300000B according to your parser....

_________________
MQ & Broker admin

kimbert

Posted: Wed May 26, 2010 4:19 am Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

It would be useful to know how this message tree was created. If it was created by a parser, which domain was used, and what happened to the message tree afterwards?

Esa

Posted: Wed May 26, 2010 4:50 am Post subject: Re: NameValue+ vs Name+/Value+

Grand Master

Joined: 22 May 2008
Posts: 1387
Location: Finland

Herbert wrote:

Hi,

Below a snippet from a trace node:

Code:

The first one seems like an XML attribute and the second one is an element. But it is not XMLNSC parser, maybe XMLNS or something.

I think you may just have a simple namespace problem. Try to access the field like this:

Code:

DECLARE myprefix NAMESPACE 'http://www.xxx.com/dds';

SET OutputRoot.XXX.yyy.whatever = InputRoot.<parsername>.xxx.myprefix:Dat02;

Herbert

Posted: Wed May 26, 2010 5:29 am Post subject: Re: NameValue+ vs Name+/Value+

Centurion

Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands

fjb_saper wrote:

Herbert wrote:

...

Code:

Wat is the difference between those 2 fields?

The input XML that results in this tree is the same for both fields. (the namespace is declared as a default namespace at the XML root element)

<Dat01>...</Dat01>
<Dat02>...</Dat02>

And I parse it with the MRM parser in XML Wire format. The definition of those 2 fields in the original XSD that was imported to generate the MRM is not the same.

Code:

<xs:element name="Dat01" type="TmstType">
<xs:element ref="Dat02"/>

<xs:simpleType name="TmstType">
<xs:annotation>
   <xs:documentation>Time Stamp.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>

<xsd:element name="Dat02" type="DattType">
<xsd:annotation>
   <xsd:documentation>Expiry Date.</xsd:documentation>
</xsd:annotation>
</xsd:element>

<xs:simpleType name="DattType">
<xs:restriction>
   <xs:simpleType>
      <xs:list itemType="xs:date"/>
   </xs:simpleType>
<xs:minLength value="0"/>
<xs:maxLength value="1"/>
</xs:restriction>
</xs:simpleType>

Dat01 is xs:dateTime as 1 simpleType deep, Dat02 is xs:date as 2 simpleType's deep, a list? I think that explains the extra level in the trace. I don't understand why it is designed like this. ( it's external ) My XML-Spy version (2005 sp2) is also confused, if I ask to generate XML from the XSD then it does give a value for Dat01 but for Dat02 it generates a empty element <Dat02/>

Quote:

For more details check out the significance of the types 0x01000013 and 0x0200000B, 0x0300000B according to your parser....

Jeff and you are refering to below URL ?

http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/as08560_.htm

The 2 values as given in the trace, (0x01000013 0x0200000B), are not in the MRM table on that URL. (according to Google *.ibm.com has no page with the string 0x0200000B, mqseries.net has this string 2 times, see below).

I'm a bit confused about those codes, for example the MRM root has in the trace output below line.

(0x01000021:Name+):MRM = ( ['mrm' : 0x115b9c630]

However that page gives below value for MRM root.

MrmRoot 0x01000008

Btw: The same problem is posted twice before.

http://www.mqseries.net/phpBB2/viewtopic.php?t=49876
http://www.mqseries.net/phpBB2/viewtopic.php?t=49720

The first thread has no solution, the problem was solved by switching to XMLNSC. ( and then Kimbert did give a ThumbsUp smiley

)

In the second thread the OP did found a solution, a simple solution. So it's 1 more level? Then just add .*[< 1] in ESQL.

For Kimbert: It's a project standard that all input/output must be MRM ...

mqjeff

Posted: Wed May 26, 2010 5:43 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

That is the table I was referring to (although that was fj's quote, not mine). If you'd said "MRM XML" before I asked, then I'd have been just as confused about those constants as you are now.

You really should raise the question of MRM versus XMLNSC-validated with XSDZips with your project team or management team. As a standard, it's very close to being obsolete and is imposing a performance hit unnecessarily.

Herbert

Posted: Wed May 26, 2010 6:04 am Post subject:

Centurion

Joined: 05 Dec 2006
Posts: 146
Location: Leersum, The Netherlands

I understand now why the MRM parser generates a extra level. RTFM at W3C did learn me that it is possible to have a list in XSD/XML. If the value 1 is changed into 3 in below XSD definition.

<xs:maxLength value="1"/>

Then below XML is possible, Dat02 will then contain a list of 3 dates.

<Dat02>2010-05-25 2010-05-25 2010-05-25</Dat02>

It does make sence that the MRM parser generate a extra level. I assume it will then have 3 'value' childs for the 1 'name' parent.

So MRM XML may soon be obsoleted, it also has parts that are not documented

kimbert

Posted: Wed May 26, 2010 8:26 am Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Quote:

For Kimbert: It's a project standard that all input/output must be MRM ...

I'm listening...what are the reasons for that?

Quote:

So MRM XML may soon be obsoleted, it also has parts that are not documented

It will be supported by IBM for a long time yet, but you will pay a heavy price for using it. It's a lot slower than XMLNSC, and is likely to throw up issues like this one.

Display posts from previous:

Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » NameValue+ vs Name+/Value+

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