aspose file tools*
The moose likes Web Services Certification (SCDJWS/OCEJWSD) and the fly likes please help to explain this sentence in the book of MH Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Services Certification (SCDJWS/OCEJWSD)
Bookmark "please help to explain this sentence in the book of MH" Watch "please help to explain this sentence in the book of MH" New topic
Author

please help to explain this sentence in the book of MH

david wangwang
Greenhorn

Joined: Jan 02, 2007
Posts: 9
"It is important to note that you can not use the xml schema import statement to import an xml schema directly from the types element of some other WSDL document." Please give me a senario.
Jim Janssens
Ranch Hand

Joined: Sep 24, 2004
Posts: 210
There are two import functions. The first is the wsdl:import element. This element is used only to import other WSDL files. You also have the xs:import. The xs:import may only be used inside a <xs:schema> element which you can find in the wsdl:types element. The xs:import may only import files that begin with <xs:schema> (thus importing only other XSD's).

RMH means that, inside an <xs:schema> within the wsdl:types element, you cannot import schema's declared inside the wsd:types element of other WSDL files. This is only logical, since this would mean importing another WSDL file, and that is not allowed for the xs:import.

Example:

The first WSDL file defines a schema inside the wsdl:types element:



The second WSDL file needs to use an element from the schema defined in the previous WSDL file. You can do this by importing the complete WSDL file, and simply re-use the schema element in the wsdl:message for example:



I'm not 100% sure if this is BP conformant, but I cannot find anything against this in the spec...

The second possiblity would be that you externalize the schema. This way you endup having 3 files. 1 XSD file, and 2 WSDL files each refering to that same XSD.

For example:



So, the WSDL1 (and WSDL2) would look liket this:



Note that there is no targetNamespace defined in the schema defined in the wsdl:types. Since you are not defining any elements in that schema (you are just using it to import another schema which contains what you need) you are allowed to bypass the targetNamespaces (but you MAY IMHO). Follow paragraph from the BP illustrates this:

R2105 All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s).
[ January 03, 2007: Message edited by: Jim Janssens ]
david wangwang
Greenhorn

Joined: Jan 02, 2007
Posts: 9
Thanks a lot.
Jim Janssens
Ranch Hand

Joined: Sep 24, 2004
Posts: 210
Hmm, it seems that the first solution I explained seems not BP conformant and is even not allowed. Allthough my WSDL validates.

The idea is that when you import a WSDL the visibility restrains you from using schema's in that WSDL. Either schemas specifically defined in the imported WSDL, or schema's imported in the imported WSDL.
Therefore if you use a schema, the schema should always be in the CURRENT WSDL, either directly or imported.

Now, what IS allowed, is to import the wsdl:message from the other WSDL (and is the portType, binding and so forth). So, if import WSDL1 in WSDL2, you cannot (may not) re-use the schema's defined or imported in that WSDL. But you MAY re-use the messages defined in that WSDL that use the schemas from that WSDL.

The second solution, having the schema in a separate XSD file, remains valid.

I got this information from the follwing link (explained very good imho)
-> https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/594

In the WSDL spec itself, you can also find this more or less:
-> http://www.w3.org/TR/wsdl



It does not state 'types' or 'schema'.

If anyone here can confirm this I would be happy too
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
I've found that many SOAP layers will permit things that aren't strictly in compliance with the standard (and some will reject things that are).
So using a WSDL validator to determine whether something is really valid WSDL isn't going to give more than a broad indication (if it validates it's more likely to be valid than when it doesn't) but that's as far as it goes.

The source generator from .NET 2.0 is one of the best I've tried so far. It will yield warnings in many places where Axis for example silently agrees with your invalid WSDL.
Things like overloaded methods for example aren't allowed according to the spec, .NET gives a warning but generates them where Axis just goes ahead and gives you the green light.


42
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: please help to explain this sentence in the book of MH