XML Retriever retrieves files only if they are defined in schemaLocation.

See getAllLocationOfReferencedEntities(File parsedFile) in
org.netbeans.modules.xml.retriever.impl.DocumentTypeSchemaWsdlParser

For schema files, schemaLocation is optional. The namespace should be used to retrieve the file.

Assigning to retriever module.

This was filed on behalf of a mailing list question on nbusers mailing list.

Namespace can't possibly be used to find a document. I'm not sure how you would be able to find a document w/o the
location. Sorry, this is not a bug.

http://www.w3.org/TR/xmlschema-1/#schema_reference
See #5 in Schema Representation Constraint: Schema Document Location Strategy

Fair enough, this is very useful. Let me see if this is possible to fix it in 6.0 or not?

On a second look at the wsdl file, there is no schemaLocation in the first place. I added that manually and the
validation works.

- <import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
+ <import namespace="http://schemas.xmlsoap.org/soap/encoding/"
schemaLocation="http://schemas.xmlsoap.org/soap/encoding/" />

i understand that part that there is a work around.
 
But schemaLocation is optional. And I have seen lots of usages of xsd:import with no schemaLocation, but only namespace.
If schemaLocation is not present, then the retriever should try to retrieve the document using the namespace as per the
spec.

Please see:
- http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#xsi_schemaLocation
- http://www.w3.org/TR/xmlschema-0/#schemaLocation

The schemaLocation or noNamespaceSchemaLocation attributes are read by the validating processors to find the schemas.

We need to use namespace as schemaLocation and at least try to fetch the schema if schemaLocation is missing.
We need to then store it in project catalog.

see attached mail for context:

Created attachment 51254 [details]
mail discussion

Created attachment 51255 [details]
same mail discussion in thunderbird format

Product Version: NetBeans IDE 6.0 Beta 2 (Build 200710181000)
Java: 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-87
System: Mac OS X version 10.4.10 running on i386; MacRoman; en_US (nb)

Following the Steps:
1. Create a bpel module
2. Create a new External WSDL Document from http://geocoder.us/dist/eg/clients/GeoCoderPHP.wsdl
3. Validate the wsdl

Output:
XML validation started.
0 Error(s),  0 Warning(s).
XML validation finished

tony, try with a later build. see IZ 119402

Still waiting for a new build, Build 200710181000 was the last one...

Product Version: NetBeans IDE 6.0 Beta 2 (Build 200710190908)
Java: 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-87
System: Mac OS X version 10.4.10 running on i386; MacRoman; en_US (nb)

I am able to reproduce thins in the latest Beta2 build.

XML validation started.
Users/Tony/NetBeansProjects/BpelModule1/src/geocoder.us/dist/eg/clients/GeoCoderPHP.wsdl:15,15
Error: src-resolve: Cannot resolve the name 'SOAP-ENC:Array' to a(n) 'type definition' component.

1 Error(s),  0 Warning(s).
XML validation finished

Here is my response to the attached email threads here:
---------
Hi Ritesh,
There is a workaround for this fix. For 6.0, I recommend using the workaround.

Since this is a user requirement, soon after 6.0, I can work on this and get it resolved. I do not recommend making any
changes at this point for 6.0. We do not necessarily have to have a spi to address this issue. If this is indeed a
standard practice, we might as well have it part of our core resolving and fetching algorithm.

Thanks
-- Sam
---------

Tony, try the workaround as well.

Work around works:

Replace:

<import namespace="http://schemas.xmlsoap.org/soap/encoding/" />

with

<import namespace="http://schemas.xmlsoap.org/soap/encoding/" schemaLocation="http://schemas.xmlsoap.org/soap/encoding/" />

Enhancement is a better issue type.