The question about how to remove a namespace declaration is discussed in AXIOM-75.
Andreas On Wed, Nov 23, 2011 at 01:20, Charith Wickramarachchi <[email protected]> wrote: > > > On Tue, Nov 22, 2011 at 6:48 PM, Ruwan Linton <[email protected]> > wrote: >> >> Hi Charith, >> >> Have you tried changing the namespace prefix within Synapse. I am not too >> sure whether AXIOM normalizes that as well, but if it doesn't that might >> solve the problem. I know xsi is a special case, but I am assuming xsi is >> not hard coded in the SAML processor BE that you are referring to. >> > > > Hi Ruwan , > > I was previously trying to remove the namespace declaration with in the > synapse from the SOAP envelope level as Andreas suggested. As in this case > client and BE service are legacies to me. But I couldn't find any Axiom api > to do that. In my case i can't touch this assertion element as it's a signed > one. > > thanks, > Charith > >> >> Thanks, >> Ruwan >> >> On Tue, Nov 22, 2011 at 6:36 PM, Andreas Veithen >> <[email protected]> wrote: >>> >>> Well, the problem is that that specification actually contradicts what >>> you are saying. You can find the relevant quote in section 2.1 "Data >>> Model": >>> >>> "An element E has namespace nodes that represent its namespace >>> declarations as well as any namespace declarations made by its >>> ancestors that have not been overridden in E's declarations, the >>> default namespace if it is non-empty, and the declaration of the >>> prefix xml." >>> >>> Removing a redundant namespace declaration therefore doesn't change >>> the data model because that declaration is "restored" by virtue of the >>> second part of that definition. Therefore the output of the >>> canonicalization (and hence the signature) doesn't change. >>> >>> Andreas >>> >>> Note: the superfluous namespace declarations implied by this >>> definition are eliminated by the following rule specified in section >>> 2.3 "Processing Model": >>> >>> "A namespace node N is ignored if the nearest ancestor element of the >>> node's parent element that is in the node-set has a namespace node in >>> the node-set with the same local name and value as N. Otherwise, >>> process the namespace node N in the same way as an attribute node, >>> except assign the local name xmlns to the default namespace node if it >>> exists (in XPath, the default namespace node has an empty URI and >>> local name)." >>> >>> On Tue, Nov 22, 2011 at 13:31, Sanjiva Weerawarana >>> <[email protected]> wrote: >>> > http://www.w3.org/TR/xml-c14n >>> > >>> > On Tue, Nov 22, 2011 at 5:59 PM, Sanjiva Weerawarana >>> > <[email protected]> >>> > wrote: >>> >> >>> >> Please look at the C14N spec. >>> >> >>> >> On Tue, Nov 22, 2011 at 4:00 PM, Andreas Veithen >>> >> <[email protected]> wrote: >>> >>> >>> >>> Sanjiva, >>> >>> >>> >>> Can you substantiate these claims by references to the spec or >>> >>> concrete examples? >>> >>> >>> >>> Andreas >>> >>> >>> >>> On Tue, Nov 22, 2011 at 03:51, Sanjiva Weerawarana >>> >>> <[email protected]> wrote: >>> >>> > Thanks for the clear writeup Andreas. >>> >>> > On Tue, Nov 22, 2011 at 12:41 AM, Andreas Veithen >>> >>> > <[email protected]> wrote: >>> >>> >> >>> >>> >> removal of redundant namespace declarations? I don't know the C14N >>> >>> >> specs well enough to answer that question, but I've seen that >>> >>> >> these >>> >>> >> specs make provisions to preserve the namespace context of the >>> >>> >> element >>> >>> >> and also define an algorithm to remove redundant namespace >>> >>> >> declarations (search for "superfluous" or "unnecessary" namespace >>> >>> >> declarations through the specs). >>> >>> > >>> >>> > Simple answer is that yes the spec is sensitive to any nodes being >>> >>> > removed, >>> >>> > including seemingly redundant namespace nodes. As Alek noted, with >>> >>> > the >>> >>> > advent of XPath, its now possible for a namespace declaration that >>> >>> > looks >>> >>> > redundant to an XML parser to actually be required. However this >>> >>> > case >>> >>> > is >>> >>> > simpler- the element is signed and removing the node breaks the >>> >>> > signature. >>> >>> > I think we need to have a way to say "don't mess with the XML >>> >>> > serialization >>> >>> > AT ALL" .. that is what we want in the case of Synapse is not just >>> >>> > an >>> >>> > infoset preserving serialization but rather the EXACT >>> >>> > serialization. >>> >>> > Sanjiva. >>> >>> > -- >>> >>> > Sanjiva Weerawarana, Ph.D. >>> >>> > Founder, Director & Chief Scientist; Lanka Software Foundation; >>> >>> > http://www.opensource.lk/ >>> >>> > Founder, Chairman & CEO; WSO2; http://wso2.com/ >>> >>> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ >>> >>> > Member; Apache Software Foundation; http://www.apache.org/ >>> >>> > Visiting Lecturer; University of Moratuwa; >>> >>> > http://www.cse.mrt.ac.lk/ >>> >>> > >>> >>> > Blog: http://sanjiva.weerawarana.org/ >>> >>> > >>> >>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: [email protected] >>> >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Sanjiva Weerawarana, Ph.D. >>> >> Founder, Director & Chief Scientist; Lanka Software Foundation; >>> >> http://www.opensource.lk/ >>> >> Founder, Chairman & CEO; WSO2; http://wso2.com/ >>> >> Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ >>> >> Member; Apache Software Foundation; http://www.apache.org/ >>> >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >>> >> >>> >> Blog: http://sanjiva.weerawarana.org/ >>> > >>> > >>> > >>> > -- >>> > Sanjiva Weerawarana, Ph.D. >>> > Founder, Director & Chief Scientist; Lanka Software Foundation; >>> > http://www.opensource.lk/ >>> > Founder, Chairman & CEO; WSO2; http://wso2.com/ >>> > Founder & Director; Thinkcube Systems; http://www.thinkcube.com/ >>> > Member; Apache Software Foundation; http://www.apache.org/ >>> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >>> > >>> > Blog: http://sanjiva.weerawarana.org/ >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Ruwan Linton >> Member, Apache Software Foundation; http://www.apache.org >> Director of Engineering; http://adroitlogic.org >> >> phone: +94 11 282 7532 >> email: [email protected]; cell: +94 77 341 3097 >> blog: http://blog.ruwan.org >> linkedin: http://www.linkedin.com/in/ruwanlinton >> google: http://www.google.com/profiles/ruwan.linton >> tweet: http://twitter.com/ruwanlinton > > > > -- > Charith Dhanushka Wickramarachchi > http://charithwiki.blogspot.com/ > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
