Re: Schemas in imported WSDL

On Fri, 14 Nov 2003 15:07:33 -0500
Glen Daniels <gdaniels@sonicsoftware.com> wrote:
> OK, now I'm confused. :)
> 
> I would certainly a) LIKE this to be the case, and b) like the
> spec/primer to say something about it, but I'm surprised to hear you
> say this, Gudge, after the earlier conversation.  I thought when you
> said "The schema constructs defined in Schema C are only visible to
> WSDL B, they are not visible to WSDL A", you meant that they were not
> visible even in the face of an explicit"xs:import".  I gather that was
> Amy's interpretation as well, judging from her message.
> 
> Are you saying that WSDL processors may do this, should do this, or
> must do this (where "this" == "make the schema in WSDL B available for
> import to WSDL A via xs:import")?

I don't think this is as straightforward as Gudge seems to suggest.  The
reason has to do with implementation of cataloging.

Let's use some names for shorthand.  WSDL B contains (embeds) schema S. 
WSDL A imports WSDL B.  WSDL A imports only WSDL B.  WSDL A' imports
WSDL B and schema-imports schema S.  Okay?

Here's the deal: namespace resolution, when schema is involved,
generally requires some level of cataloging.  Let's take a couple of
models.

Model one.  We're going to create a top-level, global cache of
namespaces.  We sort of need to do this, because there are several
namespaces (xsd, xsi, xml, xmlns) that are *always* in scope, and we
don't want to have to run out over the internet to collect them.  This
is pretty much a given for any design; these things are built-in, and an
easy way to do that is to go ahead and create a cache, or catalog, where
they are accessible by namespace.

Now, we read WSDL B, and store it, tagged with type ("WSDL"), namespace
("B"), and location ("Lb") in the global cache.  In the process, we
encounter schema S, and store it tagged with type ("WXS"), namespace
("S"), and location (NULL) into the global cache.

Next, we read WSDL A.  It contains an import of namespace B, which we
find in the cache, with a matching type.  The import contains a
location, which we can either verify or ignore.  WSDL A also access
schema types from namespace S, but ... namespace S is not in scope. 
Error!

Next, we read WSDL A'.  It contains an import of namespace B, which we
find in the cache, with a matching type.  The import contains a
location, which we can either verify or ignore.  Then there's a
schema-import of schema S, which we find in the cache with a matching
namespace and type.  Location in the cache is null, and is null in our
import.  All serene; A' accesses schema types from namespace S, and
finds them.

Model Two.  Again, there's a top-level, global cache of namespaces, for
the same reasons as before.  However, in this model we also create a
cache/catalog associated with each namespace, showing the namespaces in
scope, and hooking to its parent namespace's catalog for further
resolution.  In the previous example, we read B before we read A; it
didn't matter, because everything went into the top-level cache.  In
this case, it *will* matter, so we'll do it in order.

First, we read WSDL A.  It's top-level, so its resolver is connected to
the top-level catalog for those cases where it finds no match.  It
imports WSDL B.  Namespace B, of type WSDL, and location Lb, is added to
catalog Ac.  We create a new catalog associated with B (Bc), and parse
B.  It contains an import of schema S, which is placed in catalog Bc,
with type WXS and location null.  All parses correctly so far.  WSDL A
now references (without importing) types in namespace S.  It looks in
catalog Ac for namespace=S, type=WXS; no match.  It asks the global
catalog.  No match.  Error!

Next, we read WSDL A'.  It's top-level, so its catalog Ac is connected
to the top-level catalog.  It imports WSDL B.  Namespace B, of type WSDL
and location Lb, is added to catalog Ac.  We create a new catalog Bc
associated with B, and parse B.  In parsing, we find the import of
schema S, which is placed in catalog Bc with type WXS and location null.
 All parses correctly so far.  We return to WSDL A, which now imports
schema S.  It examines Ac for namespace=S, type=WXS, no match.  It asks
the global catalog.  No match.  Error!

Summary: with cascaded, scoped catalogs, the schema import of S in A'
would fail, but with a global catalog implementation, it would succeed. 
The use of schema types without import in A should always fail.

Is that more clear?  Basically, I don't think that the position being
taken, that it SHOULD always work, is necessarily correct.  I believe it
depends upon catalog implementation, and I don't believe that the schema
specification has any mandate one way or the other.

In the global model, there is one catalog, and everything is in it.  The
attraction of this model is that everything, once seen, is findable
again.  The drawback is that it is possible (and even likely, especially
in the case of the unnamed-namespace; xsd does not require a
targetNamespace attribute) to have collisions, and it then becomes
necessary to develop an algorithm to choose the best from several
candidates.  It may also be necessary (when location differs, for
instance) to determine equivalence of two schemas.

In the scoped model, each new namespace creates a new, scoped catalog,
and they only connect "upwards".  So, the global namespace contains the
pre-defined bits, and it also contains the top-level bits.  In our
example, there are catalogs GlobalC, A'c, Bc, and Sc.  GlobalC contains
A' (and global stuff); A'c contains B; Bc contains S; Sc is empty. 
There's less need to invent heuristics, because scope is the operative
algorithm: the first match is "best".

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 14 November 2003 16:08:49 UTC