The thing is that I am not convinced that one should have to use the `schemaLocation` attribute to override the location of a schema to be fetched using a catalog. At least in the JAX-WS `wsimport` tool that ships with standard Oracle Java 7, one is able to provide alternative locations for schemas that are simply referenced with an <import> element, without `schemaLocation` attributes. So I am giving the same catalog to both `wsimport` and `wsdl2java` tools, and only `wsdl2java` is unable to use the correct entry in the catalog, that's why I suspect this to be a bug. I dunno perhaps I should file a bug report.
On Fri, Sep 27, 2013 at 12:59 AM, Aki Yoshida <[email protected]> wrote: > hi, > sorry for my short reply earlier. > > the publicId identifier is an old time identifier and has a different > usage and syntax from the URLs. > http://en.wikipedia.org/wiki/Formal_Public_Identifier > > For redirecting URLs to somewhere else, you can use system or > rewriteSystem entries. > So, I thought my quick reply would solve your issue, assuming the > lookup to fall back to use the namespace URL of the import when its > schemaLocation attribute is not set. > > But it looks like this assumption was wrong. In other words, the > schemaLocation must be set when the schema needs to be retrieved. > > In that case, I was wondering where you get the schema that omits the > schemaLocation attribute and if it can be processed by other schema > based tools. > > regards, aki > > 2013/9/26 Menelaos Perdikeas <[email protected]>: > > Changing the catalog entry from > > > > <public publicId="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; > > uri="STCcoords-v1.10.xsd"/> > > > > to: > > > > <system systemId="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; > > uri="STCcoords-v1.10.xsd"/> > > > > still requires adding the `schemeLocation` attribute in the `<import>` > > element otherwise the types of the imported schema are not found. > > That is, I still need to modify the XSD schema (which only has an > > `<import>` element without a `schemaLocation` attribute). > > Can you elaborate a bit more on public versus system entries? I am not > sure > > I get all the nuances. > > > > > > On Thu, Sep 26, 2013 at 5:42 PM, Aki Yoshida <[email protected]> wrote: > > > >> that's not a public id. > >> can you use the system entry instead? > >> > >> > >> 2013/9/26 Menelaos Perdikeas <[email protected]>: > >> > I am using Apache CXF 2.7.6 `wsdl2java` and it seems that the tool > >> ignores > >> > or fails to find public catalog entries. In particular I have the > >> following > >> > `<xs:import>` in one of my XSD files: > >> > > >> > <xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10 > "/> > >> > > >> > The above cannot be properly resolved with the catalog file entry: > >> > > >> > <public publicId="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; > >> > uri="STCcoords-v1.10.xsd"/> > >> > > >> > If I change the `<xs:import>` by adding a `schemaLocation` attribute, > >> i.e. > >> > change it to: > >> > > >> > <xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10 > " > >> > schemaLocation="http://www.ivoa.net/xml/STC/STCcoords/v1.10/> > >> > > >> > It resolves files, but my understanding is that this shouldn't have > been > >> > necessary as I don't want to have to edit the XSD I am provided with. > >> > > >> > The behavior is the same whether OASIS XML format or TR9401 format is > >> used. > >> > Kind Regards, > >> > Menelaus. > >> > -- at Thy word I will let down the net.
