If you have several schemas in a wsdl file that refer to one another, the
one making the reference must import the other **in order to validate
against the schemas**. Axis definitely, and .Net likely do not validate the
soap messages because performance would suffer, and probably because there
is quite a lot of invalid stuff coming out of extant web services (E.g., a
few months ago, Amazon and Google both produced stuff involving SOAP array
types that couldn't be validated at one time, using a pattern that was
incorrectly written as examples into some early version of the WSDL spec or
some tutorial material on it.) Obviously in order to import the schema, the
schema processor handling the wsdl file must be able to find the other
schema, and the specification of the location for the imported schema cannot
be done with a URI unless it contains some kind of fragment specifier and
the processor's entity resolve knows how to process those fragment
specifications. This is non-standard, and you can be sure the Axis and .Net
parsers probably don't know how to do this.
I have written code to find all the imported schemas mentioned in wsdl
files, and WSIF contains some machinery to do this also.
Jeff
----- Original Message -----
From: "Anne Thomas Manes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 21, 2003 10:23 AM
Subject: Re: schema imports
Personally, I find the Schema specification pretty much infathomable. Below
is the text that I think describes the situation. Based on the sentence "no
element information item can be fully assessed unless all the components
required by any aspect of its (potentially recursive) ·assessment· are
present in the schema", I would say that your vendor is correct, because
the "schema" (as defined by the <schema> element) doesn't have the type
definition defined within it.
But I'm not a schema expert...
Anne
·assessment· is defined with reference to an ·XML Schema· (note not a
·schema document·) which consists of (at a minimum) the set of schema
components (definitions and declarations) required for that ·assessment·.
This is not a circular definition, but rather a post facto observation: no
element information item can be fully assessed unless all the components
required by any aspect of its (potentially recursive) ·assessment· are
present in the schema.
As specified above, each schema component is associated directly or
indirectly with a target namespace, or explicitly with no namespace. In the
case of multi-namespace documents, components for more than one target
namespace will co-exist in a schema.
Processors have the option to assemble (and perhaps to optimize or
pre-compile) the entire schema prior to the start of an ·assessment·
episode, or to gather the schema lazily as individual components are
required. In all cases it is required that:
* The processor succeed in locating the ·schema components·
transitively required to complete an ·assessment· (note that components
derived from ·schema documents· can be integrated with components obtained
through other means);
* no definition or declaration changes once it has been established;
* if the processor chooses to acquire declarations and definitions
dynamically, that there be no side effects of such dynamic acquisition that
would cause the results of ·assessment· to differ from that which would
have been obtained from the same schema components acquired in bulk.
NOTE: the ·assessment· core is defined in terms of schema components at the
abstract level, and no mention is made of the schema definition syntax
(i.e. <schema>). Although many processors will acquire schemas in this
format, others may operate on compiled representations, on a programmatic
representation as exposed in some programming language, etc.
The obligation of a schema-aware processor as far as the ·assessment· core
is concerned is to implement one or more of the options for ·assessment·
given below in Assessing Schema-Validity (§5.2). Neither the choice of
element information item for that ·assessment·, nor which of the means of
initiating ·assessment· are used, is within the scope of this specification.
At 11:28 AM 8/21/2003 -0500, you wrote:
>Given the following WSDL document (obviously paraphrased):
>
><definitions xmlns:foo="foo" xmlns:bar="bar">
> <types>
> <schema targetNamespace="foo">
> <complexType name="complexFoo">
> <element name="elementFoo"
> type="bar:complexBar"/>
> </complexType>
> </schema>
> <schema targetNamespace="bar">
> <complexType name="complexBar">
> ...
> </complexType>
> <schema>
> </types>
> ...
><definitions>
>
>Is the reference to element complexBar from namespace "bar" valid in
>namespace "foo" (when elementFoo is of type complexBar) or do I need an
>explicit schema import declaration and if so -- how is that done
>here? I'm working with a vendor who is disputing the validity of WSDL
>formed much like this but Axis and .Net swallow the WSDL just fine and
>interact with my service just as I would expect.
>
>Futhermore, they're attempting to tell me that the namespace must
>reference something concrete. Their assertions seem a bit cracked induced
>but I'm looking for someone to back me up here before I act the fool.
>
>Thanks,
>Cory Wilkerson
