[bpel-dev] Re: Schema questions

[James Moody <James_Moody@xxxxxxxxxx>]

(Michal had problems sending the original to the list,
so I'm forwarding it with my reply).

Hi Michal,

So let's talk first about XSD (ignoring both WSDL
and BPEL) because this might simplify the story somewhat. In the Eclipse
XSD model, you can do something like the following:

XSDSchema schema = // Let's load a schema from an
XSD file here
XSDTypeDefinition def = schema.resolveTypeDefinition(namespace,
localPart);

This resolves the type definition with respect to
that schema (taking into account imports and includes). I've looked at
the implementation, and it boils down to is that it iterates over all possibilities
and returns the first one that matches. So if you have two with the same
namespace/name pair, you'll get one of them back. You'll get the same one
each time (provided you don't re-order the imports, for example), so I
guess that's good news anyway. :-)

Add WSDL to the mix and the story is the same - with
the addition that the WSDL file itself can contain schema definitions which
are candidates for matching. Then the definition will iterate through the
web of imports and includes and find the first match.

Now back up to BPEL. First of all, with regard to
your comment about scoped partner links below, I don't think this actually
affects things - from the way I understand it, it's not the *reference*
from the partner link that makes things in that namespace "available";
instead it's the import. Since imports are global and not scoped, then
there's no issue with scoping visibility of XSDs (and WSDLs). Feel free
to correct me if I've misinterpreted. You say that in your implementation
you allow the upward visibility - in the initial open source implementation
we do as well.

We have logic in our bpel model (specifically in BPELResourceImpl)
that does effectively what the WSDL and XSD models do - iterate through
the imports and look for things, returning the first match. So we're consistent,
at any rate. It's actually slightly simpler than the wsdl and xsd since
we don't have to look in our own file first (since you can't define xsd
inline in a bpel process). The BPEL spec is notoriously vague about how
these imports are supposed to behave (it basically says "do it kind
of like wsdl and xsd do") so we're kind of left on our own in interpretation
of a few points. For example, does an import of wsdl type import xsd types
declared in the same wsdl file? What if the schema in the wsdl file has
a different namespace than the wsdl definition - which namespace should
you import? In that case, should it be an XSD-type of import or a WSDL-type
of import (since bpel does distinguish)? Should all imports of XSD types/elements
be XSD imports, even if the XSD types live in WSDL files? You get the picture.

Hope this helps.

james


> 
> ----- Message from Michal Chmielewski <michal.chmielewski@oracle.
> com> on Wed, 11 Jan 2006 12:26:24 -0800 -----
> 
> To:
> 
> "BPEL Designer project developer discussions." <bpel-dev@xxxxxxxxxxx>
> 
> Subject:
> 
> Schema questions ...
> 
> James,
> 
> My questions about schema in the Eclipse schema model.
> 
> A single WSDL will import or include schema definitions creating 
> effectively a type system T1 = (xmlns-1,..., xmlns-N) where xmlns-?
are 
> namespaces that define some type structures.  In practice, you
may have 
> Tn = (xmlns-n-1,xmlns-n-2,...xmlns-n-M)
> 
> With n such type systems defined by each of the wsdl files you really
> have to resolve T which is the ubber type system for the process which
> is basically the union of  T1,T2, ...,Tn.
> 
> There is no problem if for any i and j, Ti ^ Tj = empty, that is no
2 
> wsdl ever import types in the same namespace. The problem if Ti ^
Tj = 
> non-empty. Then there exists one namespace that is imported in 2 
> different places. Clearly, you can take a union of the types and push
> them into the ubber type system T. Best case, you have different types
> in these 2 physical definitions, worse case you have a conflict (
same 
> type defined differently in 2 physical locations).
> 
> So my question is about  the eclipse XSD model API:
> 
> a) Can a container defining T be created (indexed by namespaces)
> b) Can XSD definitions be added to T and the API do type conflict
> detection ?
> c) Can the API be instructed to pick one or the other ?
> 
> Or do we have to do this ourselves ?
> 
> The type system of the process during construction will change as
> partner links are added and removed. So this type of functionality
is 
> essential. I really need to read more about it but I wanted to get
> feeling as to how much work if any there would be.
> 
>  From a BPEL perspective, I thought originally this problem would
> compound itself when locally scoped partner links were used. Simply
> because, semantically at least, the partner link is defined locally
in a 
> scope and has no upward visibility. So should the types be visible
> upward or not ? I don't think the BPEL spec talks about this so and
as 
> in our implementation we simply allow it.
> 
> -m
> 
> 
> [attachment "michal.chmielewski.vcf" deleted by James 
> Moody/Ottawa/IBM] [attachment "michal.chmielewski.vcf" deleted
by 
> James Moody/Ottawa/IBM] [attachment "michal.chmielewski.vcf"
deleted
> by James Moody/Ottawa/IBM]