axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <>
Subject RE: schema import issue
Date Wed, 17 Apr 2002 14:31:24 GMT
I  don't believe we need this for beta 2.

What we have to change is, where-ever we have soap-enc, we have to add an
import.  But since most other WSDL creators (ALL of them?) don't have this
import, we should probably accept WSDL that doesn't have it (otherwise much
of our interop will probably fail!).  So with that in mind, I don't think
we'd gain anything by getting this into beta 2.

Russell Butek

Tom Jordahl <> on 04/17/2002 09:09:45 AM

Please respond to

To:    "''" <>
Subject:    RE: schema import issue

Hey Russell,

Do we need this soapenc support for Beta 2?

Tom Jordahl

-----Original Message-----
From: Russell Butek []
Sent: Friday, April 12, 2002 10:00 AM
Subject: schema import issue

I've just had a bit of education about XML imports.  We have a slight
problem.  Given the pattern:

<schema xmlns:xxx="ZZZ"...>
   <... www="xxx:yyy" .../>

we MUST have an import statement like:

<import namespace="ZZZ">

There is ONLY ONE exception:  xsd types are considered built in.  For
example, the following does not need an import:

<schema xmlns:xsd=""...>
   <... type="xsd:int" .../>

What does this mean for us?  We treat soapenc types as built-in types, but
they're not, so we have to add imports to all our WSDL that contains
soapenc.  And we should probably check for the import statement in
WSDL2Java.  (I THINK someone at the soapbuilder's interop meeting pointed
this out to us, but we chose to ignore him.)

Here's a condensation of my education if you're interested.  A schema
import (NOT a WSDL import, which is a slightly different beast) has two
attributes:  namespace, schemaLocation.  schemaLocation is optional and is
treated merely as a hint.  Tools can ignore the hint.  Since soapenc types
are treated as built-in by our tools, we would ignore the schemaLocation if
it appeared in a soapenc import statement.  But any other imported type we
would probably depend on the schemaLocation, and if it wasn't there, we'd
be free to throw an exception (which I believe we do).

I'm not in the mood to tackle this right now, but I'll add it to our TODO

Russell Butek

View raw message