aspose file tools*
The moose likes Web Services and the fly likes SOAP message namespace doubt? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "SOAP message namespace doubt?" Watch "SOAP message namespace doubt?" New topic
Author

SOAP message namespace doubt?

shai ban
Ranch Hand

Joined: Jan 05, 2010
Posts: 177
If the below schema is mentioned in the WSDL:
<xsd:schema targetNamespace="http://ttdev.com/ss" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="concatRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="s1" type="xsd:string"/>
<xsd:element name="s2" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>


Then how this soap request is valid because (as far as I know) s1/s2 are not part of any namespace (parent namespace is not defined without prefix). But it should be according to Document style web services where every element can be validated through schema. I have seen this type of example in many books. Current one is picked up from Developing Web Services with Apache CXF and Axis2.
<foo:concatRequest xmlns:foo="http://ttdev.com/ss">
<s1>abc</s1>
<s2>123</s2>
</foo:concatRequest>

Thanks.
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 539
    
    3
Then how this soap request is valid because (as far as I know) s1/s2 are not part of any namespace (parent namespace is not defined without prefix).

s1 and s2 are not part of any namespace, so to speak. That is quite true. And the schema is intended to fully validate documents exactly like that. The fact that it is valid is because the schema has a default setting of an attribute called elementFormDefault to false. The elementFormDefault being false would shield the local elements from being lived in the targetNamespace the schema is defined for. However despite their not being in the targetNamespace, their construction is not less specified - and in this case, they are of type xsd:string. If that is not clear, you should consult the documentation or tutorials on the functionality of that particular attribute.
shai ban
Ranch Hand

Joined: Jan 05, 2010
Posts: 177
g tsuji wrote:
Then how this soap request is valid because (as far as I know) s1/s2 are not part of any namespace (parent namespace is not defined without prefix).

s1 and s2 are not part of any namespace, so to speak. That is quite true. And the schema is intended to fully validate documents exactly like that. The fact that it is valid is because the schema has a default setting of an attribute called elementFormDefault to false. The elementFormDefault being false would shield the local elements from being lived in the targetNamespace the schema is defined for. However despite their not being in the targetNamespace, their construction is not less specified - and in this case, they are of type xsd:string. If that is not clear, you should consult the documentation or tutorials on the functionality of that particular attribute.


As far as I understand about 'elementFormDefault' = 'false' means element need not be prefixed but it doesn't mean they shouldn't be in any namespace. So if something is like the below (snippet) then it is valid since s1/s2 are in this default namespace but they need not be prefixed as elementFormDefault=false.



g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 539
    
    3
Amendment
I said what I've to say; only that I had written too hastily the value to be taken on by elementFormDefault. I have to say elementFormDefault="unqualified" as default setting. (Whenever I said false, I meant unqualified in practice.) The attribute can take on "qualified" and "unqualified". I regret this mixed up that might confuse readers. Sorry!
-amendment off-

As far as I understand about 'elementFormDefault' = 'false' means element need not be prefixed but it doesn't mean they shouldn't be in any namespace.

That's completely wrong. Based on it, you could understand better what full-length tutorials might try to convey on that part. It is not easy reading.
shai ban
Ranch Hand

Joined: Jan 05, 2010
Posts: 177
g tsuji wrote:Amendment
I said what I've to say; only that I had written too hastily the value to be taken on by elementFormDefault. I have to say elementFormDefault="unqualified" as default setting. (Whenever I said false, I meant unqualified in practice.) The attribute can take on "qualified" and "unqualified". I regret this mixed up that might confuse readers. Sorry!
-amendment off-

As far as I understand about 'elementFormDefault' = 'false' means element need not be prefixed but it doesn't mean they shouldn't be in any namespace.

That's completely wrong. Based on it, you could understand better what full-length tutorials might try to convey on that part. It is not easy reading.


I also did the same mistake but I meant with 'unqualified' only. But still it is not clear. Could you please elaborate more with some link/example?

Thanks.
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 539
    
    3
Could you please elaborate more with some link/example?

I can refer you to w3 recommendation part 0:primer, section 3. That is fundamental, but as said, it is not a easy read.
http://www.w3.org/TR/xmlschema-0/#NS

A couple of points to bear in mind which might help in the reading of it.
[1] First, one of the reason that the subtlety came about is because there is a time lapse between the early days of xml and the appearance of namespace as the recommendation and finally the schema as a recommendation. As a result, it leads to a big free ground of no/null/empty (however it is called) namespace xml documents/elements/attributes. Then...
[2] the elementFormDefault exercises its influence on the so-called local element declarations. It is irrelevant to the element declarations which are defined globally, in the straight sense of them being directly under xs:schema root. The distinction of global vs local element declarations is an important pre-requisit to the understanding of the attribute elementFormDefault.

Returning to the concrete case: s1 and s2 can be comprehended as elements in null namespace in the sense that they make their appearance in the schema which that specific (unique to each schema) targetNamespace by xsd:import of a schema file without targetNamespace which defines the s1 and s2 as global element declarations.


With xxx.xsd being without any targetNamespace

So despite all the difficulty in wording, one can even feel it in the recommendation itself, the s1 and s2 are just like they are in no/null/empty namespace or in any case outside of the targetNamespace in the original xsd.
shai ban
Ranch Hand

Joined: Jan 05, 2010
Posts: 177
Mostly I didn't get what you said but I got the example of 'Target Namespaces & Unqualified Locals' from the w3 link.
Means you are correct. I checked in the RMH (Richard Monson Haefel) also on P.N.94. Probably I forgot that concept.

Thanks a lot for your patience.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: SOAP message namespace doubt?