no conflict as long as the namespace (and its associated XSD) are unique for example
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"; xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy";> where the actual validating xsd is located at http://axis.apache.org/axis2/java/rampart/rampart-config.xsd the target namespace attribute from the validating xsd is the xmlns:ramp from RampartConfig so *there is targetNamespace redirection involved* <xs:schema targetNamespace="http://ws.apache.org/rampart/policy"; elementFormDefault="qualified" attributeFormDefault="unqualified"> personally I dont like those redirections as it makes the developer and the parser *hunt* for accompanying targetNamespace inside the registered xsds if you want to suggest eliminating the targetNamespace redirect and go for 'direct approach' e.g. <ramp:RampartConfig xmlns:ramp="http://axis.apache.org/axis2/java/rampart/rampart-config.xsd "> i think a clear majority of axis2 developers and implementors would back you *any enhancement that eliminates obfuscation makes the tool more user-friendly and attracts more devs to implement this framework in their business or institution* go ahead and file the Request For Enhancement Martin Gainty ______________________________________________ place long-winded disclaimer here From: brianreinh...@lampreynetworks.com To: java-dev@axis.apache.org Subject: RE: rampart configs in policy.xml Date: Sat, 29 Sep 2012 06:51:38 -0400 I just expected that the only entrants in the policy would be those from the schemas. What happens if the rampart stuff is removed from the policy? (I would expect those entrants to be only in the apache-specific xmls.) From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Friday, September 28, 2012 9:16 PM To: java-dev@axis.apache.org Subject: RE: rampart configs in policy.xml Hello Brian if you get a chance to look at sts-policy-asymm-binding.xml you will see namespace assignments for both wssecurity 2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd and policy schema xsd's located at http://schemas.xmlsoap.org/ws/2004/09/policy <wsp:Policy wsu:Id="1" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";> is there a better way to ingest and parse the wssecurity and policy schemas? Martin Gainty ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. From: brianreinh...@lampreynetworks.com To: java-dev@axis.apache.org Subject: rampart configs in policy.xml Date: Fri, 28 Sep 2012 20:17:35 -0400Why is there rampart configuration information in policy.xml files? Aren’t these policy files supposed to be based upon the WS-Policy and WS-Security Policy standards? The rampart information makes them unusable in client/service applications that are not based upon the Apache projects; well, bypassing any parse and ignore. Brian Reinhold LNI tel 603 868 8411 x207 brianreinh...@lampreynetworks.com No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2221 / Virus Database: 2441/5296 - Release Date: 09/28/12
