| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| XMLNSC xsi:type |
« View previous topic :: View next topic » |
| Author |
Message
|
| Roothless |
 Posted: Tue Nov 02, 2010 1:17 am Post subject: XMLNSC xsi:type |
 |
|
Apprentice
Joined: 11 Dec 2006
Posts: 26
|
I have below scenario
Consumer soap request -> Transformation -> backend call request
Consumer soap respone <- Transformation <- bankend response
consumer expects some xsi:type in the response based on schema , but broken treats xsi:type as string in XMLNSC parser, how to get the namespace value of xsi:type?
Ex:-
<NS1:A>
<NS2:B xsi:type="NS3:ComplexType">
</NS2:B>
</NS1:A>
Message Broker doesn't recognise FIELDNAMESPACE(NS3:ComplexType)
but it works for A, B i.e FIELDNAMESPACE(NS1:A, B)
Is there anyway to extract the namespace of xsi:type complextype?
Thanks lot
_________________
MQ Toddler |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Nov 02, 2010 1:32 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| consumer expects some xsi:type in the response based on schema , but broken treats xsi:type as string in XMLNSC parser, how to get the namespace value of xsi:type? |
No need to be rude 
| Quote: |
| Message Broker doesn't recognise FIELDNAMESPACE(NS3:ComplexType); |
That's easy to explain. The parameter to FIELDNAMESPACE must be a ( reference to a ) syntax element in the message tree. You have supplied a CHARACTER value.
| Quote: |
| but it works for A, B i.e FIELDNAMESPACE(NS1:A, B) |
Yes - that's because NS1:A is a syntax element in the message tree. Your syntax looks wrong, btw - I assume you mean that NS1:B also works.
| Quote: |
| Is there anyway to extract the namespace of xsi:type complextype? |
Sort of. You can search the current element and its parents for the xmlns attribute that defines 'NS3'. However, before you do that I would like to understand the requirement. It's a fact that nobody else has asked for this before - what transformation logic do you have that needs this? |
|
| Back to top |
|
|
| Roothless |
| Posted: Tue Nov 02, 2010 2:17 am Post subject: |
|
|
Apprentice
Joined: 11 Dec 2006
Posts: 26
|
Hi,
Yes i meant works for Element B also
Consumer request has header and Body , as the backend uses FIXED LENGTH data, we need to tranform xml to non-xml and vice versa.
but , we need to send back original header with response body data,
we use Environment to keep the header , and attach response body to original envelope , as a result namespace PREFIXES are different , so end up having two prefixes for same Namespace.
Because xsi:type value , eventhough its namespace prefixed it is treated as STRING in message broker XMLNSC parser. how to get the namespace of complex type given in xsi:type='NS4:ComplexElement'
Basically i have to extract namespace value of ComplexElement here , it will be NS4 value.
so that we can replace the prefix in the response based on request message.
Thanks
_________________
MQ Toddler |
|
| Back to top |
|
|
| Roothless |
| Posted: Tue Nov 02, 2010 2:23 am Post subject: |
|
|
Apprentice
Joined: 11 Dec 2006
Posts: 26
|
Because xsi:type is treated as string there is no namespace declaration added to response message, its just a dummy value, because parser doen't parse xsi:TYPE . in this case how to parse xsi:type so that corresponding namepsace declation is added in the response
Thanks
_________________
MQ Toddler |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Nov 02, 2010 9:13 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Thanks for the details. I suspect that there is an easier way to solve your problem but I still don't understand this part:
| Quote: |
| as a result namespace PREFIXES are different , so end up having two prefixes for same Namespace. |
I don't understand why the xsi:type attribute needs to change. How are you attaching the response body to the header? Please post the ESQL if possible.
Please use [code] tags around any ESQL or XML to make it readable. |
|
| Back to top |
|
|
| Roothless |
| Posted: Wed Nov 03, 2010 1:47 am Post subject: |
|
|
Apprentice
Joined: 11 Dec 2006
Posts: 26
|
Hi Kimbert,
Yes we fixed the problem in simpler way , first extracted all the namespaces in the request messages with prefix , stored in Environment, and in the response we replaced all the prefixes with orginal prefixes by traversing the tree recursively , also we also followed same for xsi:type based on request/response schema.
The problem was , we thought broker FIELDNAMESPACE function would do the job for us, it did only the part.
Sorry, This is core banking solution for one of the bank, so you know the policy 
But Broker should handle xsi:Type and QName , and parse the stream and validate it, But Message broker considers xsi:type as string its not following rules defined in W3C
Schema Representation Constraint: QName Interpretation
Where the type of an attribute information item in a document involved in ·validation· is identified as ·QName·, its ·actual value· is composed of a [Definition:] local name and a [Definition:] namespace name. Its ·actual value· is determined based on its ·normalized value· and the containing element information item's [in-scope namespaces] following [XML-Namespaces]:
The appropriate case among the following must be true:
1 If its ·normalized value· is prefixed, then all of the following must be true:
1.1 There must be a namespace in the [in-scope namespaces] whose [prefix] matches the prefix.
1.2 its ·namespace name· is the [namespace name] of that namespace.
1.3 Its ·local name· is the portion of its ·normalized value· after the colon (':').
2 otherwise (its ·normalized value· is unprefixed) all of the following must be true:
2.1 its ·local name· is its ·normalized value·.
2.2 The appropriate case among the following must be true:
2.2.1 If there is a namespace in the [in-scope namespaces] whose [prefix] has no value, then its ·namespace name· is the [namespace name] of that namespace.
2.2.2 otherwise its ·namespace name· is ·absent·.
Thanks Kimbert
_________________
MQ Toddler |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Nov 03, 2010 4:25 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| But Broker should handle xsi:Type and QName , and parse the stream and validate it |
It actually does do all of that. XMLNSC validation is fully compliant with W3C, and xsi:type is correctly processed.
The problem is that the broker message tree is not a DOM tree. Some of the PSVI information is not available from the message tree.
The specific limitation is that QNames that are the value of an attribute or element do not get resolved into a namespace URI and name. The QNames that specify the namespace and name for tags and attributes do get resolved, which is why you were confused. |
|
| 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
|
|
|
|
