It is not redundant. Read the XML specs. Password is an element. While non-qualified subelements of a qualified element do inherit the qualified's parent namespace, this is not true for attributes. Attributes that are not explictly namespace-qualified do not inherit automatically the namespace of the element they are declared in. No namspace means excacly this - no namespace, not implictly inherit the namespace of its element [1]. According to the specs, attributes "wsse:Type" and "Type" are two different entities. George [1] http://www.w3.org/TR/xml-names/#uniqAttrs
_____ From: Marc Tremblay [mailto:[email protected]] Sent: Friday, May 29, 2009 2:24 PM To: George Stanchev Cc: [email protected] Subject: Re: WSS-148 WCF interop issue: Namespace not honored incase of attributes. I agree that's how the spec is written, but qualifying Type with the same namespace as Password, while redundant, doesn't change the semantics as far as XML is concerned. As the spec doesn't specifically forbid namespace qualifying Type, I would expect non-qualified and redundantly qualified forms to be treated as equivalent. Or am I failing to understand how XML works? M. On Fri, May 29, 2009 at 3:47 PM, George Stanchev <[email protected]> wrote: >From the specs: line 239: /wsse:UsernameToken/wsse:Password/@Type The Type attribute is clearly not namespaced. If it were WSS namespaced, then the line above should have been /wsse:UsernameToken/wsse:Password/@wsse:Type, but its not. For reference look at line 328 in the spec and you will see clearly wsu:Id attribute namespaced properly. Microsoft is clearly breaking the standard of requiring Type to be namespaced. That being said, the reality is what it is. I wonder if WSS4J devs would accept some kind of MS-compatibility mode that is turned off by default but can be turned on for WCF interoping deployments (may be via configration)... George _____ From: Marc Tremblay [mailto:[email protected]] Sent: Friday, May 29, 2009 12:27 PM To: [email protected] Subject: WSS-148 WCF interop issue: Namespace not honored incase of attributes. Hello, I have recently encountered the issue described at https://issues.apache.org/jira/browse/WSS-148 and am wondering if it doesn't make sense to allow for the Type attribute to be namespace qualified. I've examined Page 8 of the Web Services Security, UsernameToken Profile 1.1 spec and while the example XML doesn't namespace qualify the Type attribute, I don't see anywhere in the spec where it states that the Type attribute must not be namespace qualified. If fact there is no mention of namespace qualifying attributes in the spec that I can see. As such, I'd like to suggest that WSS-148 be reopened and wss4j modified to accept both unqualified and namespace qualified Type attributes on the Password element. I'd be happy to create the necessary patch. Thanks, Marc
