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 <sberyozkin@>: > 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.
