cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cogitate <monish.u...@gmail.com>
Subject Re: InTransformReader Test possible enhancement?
Date Mon, 12 Mar 2012 16:21:36 GMT
thanks aki and sergey, for taking a look at the "strange" requirements :)

it's quite straightforward - many vendors simply care about the payload and
not namespaces even though we share the wsdls and xsds ( maybe they are
using ESB with one service representing different needs of different clients
- not sure ). 
it's a bit weird but as clients we do ask them for a specific api ( as you
know, usually, services specify that ).

outgoing :
<Echo_PayloadRequest
xmlns="http://schemas.w3c.org/W3C">.....</Echo_PayloadRequest>
(i.e we really only have one default ns even for subelements of the request-
it's true sergey this may not be the general case )

Response from different vendors :
 vendor 1 : <ns0:Echo_PayloadResponse xmlns:ns0="tns"><ns1:Payload
<xmlns:ns1="None">Y</ns1:Payload></ns0:Echo_PayloadResponse> 
 vendor 2: <ns0:Echo_PayloadResponse
xmlns:ns0="schemas.vendor2.com"><ns1:Payload
<xmlns:ns1="schemas.vendor2.com/SUB">Y</ns1:Payload></ns0:Echo_PayloadResponse>

 vendor 3 : <ns0:Echo_PayloadResponse xmlns:ns0="vendor3"><ns1:Payload
<xmlns:ns1="gaga">Y</ns1:Payload></ns0:Echo_PayloadResponse> 
 
so as you see vendors are all over the place with their active namespaces
and subelements even when the XSDs are shared ( which will give them exactly
one default ns ). 

now, for every additional vendor "added" to the call out, we have to add a
mapping 
vendor1 : {tns}*,{http://schemas.w3c.org/W3C}/* and
{None}*,{http://schemas.w3c.org/W3C}/*
vendor2 : {schemas.vendor2.com}*,{http://schemas.w3c.org/W3C}/* and
{schemas.vendor2.com/SUB}*,{http://schemas.w3c.org/W3C}/*
vendor3 : {vendor3}*,{http://schemas.w3c.org/W3C}/* and
{gaga}*,{http://schemas.w3c.org/W3C}/*

i know it makes more sense for outgoing esply since the vendors might
specify some extra "augmenting" ns  - but what to do with this use case?

hopefully, it's not just specific to our case and might help others too.

thanks and regards,
-cogitate



Hi Sergey,
you are right. This use case is rather strange and actually not
xml-compliant. It can be considered a non-xml legacy (ie., xml-looking
but not xml) application connecting case.

I heard of a similar use case for the outbound direction (I think the
outbound case is more likely than the inbound case, as some old legacy
systems sometimes have such non-xml legacy interfaces).

To get the optimal solution, wecan wait a little bit to hear more from
cogitate and others about the justification for this option and their
requirements. In particular for cogitate's case, if they know the
namespaces on the original document, they can configure a few
namespace mapping rules explicitly to collapse the namespaces. That
will solve their problem without any new option.

regards, aki

2012/3/12 Sergey Beryozkin &lt;sberyozkin@&gt;:
> Hi Aki
>
> On 12/03/12 09:43, Aki Yoshida wrote:
>>
>> hi cogitate,
>> so, basically you want to remove all the namspaces and assign a new
>> one in a general way (i.e., without knowing the namespaces used in the
>> original document)?
>
>
> I'm not sure yet what specific case it would help with, do we have a
> scenario where an outgoing element has 2/3 active namespaces and the
> receiver is expecting a single namespace only ?
>
> Is it more an optimization enhancement (why type {bar}*: {foo}*) rather
> than
> anything else ?
>
>>
>> @sergey,
>> I think this will be straightforward and we can include this option.
>>
> Agreed
>
> Cheers, Sergey
>
>
>> regards, aki
>>
>

--
View this message in context: http://cxf.547215.n5.nabble.com/InTransformReader-Test-possible-enhancement-tp5554151p5558308.html
Sent from the cxf-user mailing list archive at Nabble.com.

Mime
View raw message