Why does SoapUI make a second call to get an XSD when getting a WSDL?

I'm attempting to take a set of existing WSDL and XSD files and create a SOAP API endpoint in my .Net Core application using the SoapCore NuGet package.

I have the WSDL being returned as expected by configuring SoapCore as shown here, however, when I use SoapUI to create a new SOAP project based on my WSDL, it does two requests. The first fetches the WSDL, which I would expect, and succeeds. But then it does another request on the same endpoint, but with the included querystring parameters ?xsd&name=. This causes SoapCore to fail because the request is asking for an XSD but no filename is given.

I don't know if the problem is with SoapUI, SoapCore, or my code. Why is SoapUI making this request? Is this normal? Does a Soap API endpoint have to have both a WSDL and XSD to work? I put the XSDs that I have in the same folder as the WSDL and pointed SoapCore to them as shown in the link above, but the problem remains.

I don't usually work with SOAP, so hopefully this question makes sense.

Update: Bogdan asked an interesting question about imports. The XSDs do have imports that reference other files. However, the WSDL has the XSDs embedded in the wsdl:types element. Within this tag there are also import tags, but they do not have a schemaLocation attribute. Here is an example:

<xs:import xmlns:xs="http://www.w3.org/2001/XMLSchema"
            namespace="http://www.starstandards.org/STAR" />

Could this be why SoapUI is making a call with a blank file name? Is this tag malformed or valid? What is the default path/filename for an <xs:import> if the schemaLocation attribute is not included?

Solution

Most likely your WSDL imports XML schemas and the location of the schema is something that SoapUI cannot resolve.

I'm not familiar with SoapCore to know how it resolves XSD imports, but for WSDLs in general, the imports are either:

on the same endpoint as the SOAP web service and then you access the XSDs with some URL parameters like SoapUI is trying to do, something like ?xsd&name=identifierForSchemaHere. This is similar to how you access the WSDL with ?wsdl;
or the location is some absolute URL path where you can get the XSD file.

Now to this question:

Does a Soap API endpoint have to have both a WSDL and XSD to work?

Theoretically, it needs neither.

A WSDL is like machine readable documentation. You can use tools to point to a WSDL and the tools can generate code that allows you to invoke the service, or can create server stubs that handle the SOAP details for you. But if you build a valid SOAP web service you can invoke it just fine without a WSDL if you know how to format the SOAP XML messages, by using normal documentation that you as a developer need to read to understand how to interact with the web service.

You don't need a WSDL, but most SOAP web services should provide one as a favour to the clients having to interact with the web service. When you provide a WSDL, you need to provide also XSD schemas (or the <types> section for the WSDL). A WSDL without XSD is half useful because it lacks the part that allows clients to know how to build the XML elements inside SOAP messages.