Fw: [bpel-dev] Re: Schema questions

[James Moody <James_Moody@xxxxxxxxxx>]

Second try forwarding this for Michal
- the first time didn't show up.

----- Forwarded by James
Moody/Ottawa/IBM on 02/08/2006 10:18 AM -----

Michal Chmielewski <michal.chmielewski@xxxxxxxxxx>

02/07/2006 09:43 PM

To	"BPEL Designer project developer discussions." <bpel-dev@xxxxxxxxxxx>, James Moody/Ottawa/IBM@IBMCA
cc
Subject	Re: [bpel-dev] Re: Schema questions

Michal still has problems with the e-mail to eclispse.org.
I am sending this to James so that he can post for me for now ... geeeeez.

James Moody wrote: 

(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. :-) 
That's the easy part I think but symptomatically may have
the same problem. Through some flow of imports or includes a type may be
redefined and it may be dealt predictably in some way by the schema model
API.

Let's say that for a moment that you have something I call a schema container,
SC, which is collection indexed by namespaces. Each namespace defines a
number of types in it. 

Now let's read on.

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. 
Yes, but a WSDL can now define types,
which potentially can be N schemas.
Let's assume for simplicity that these schemas in the same WSDL file are
in fact of different namespaces (ie each <schema> node has a different
namespace). 

Then having my SC, the schema container, I can just add SC [ns] to it for
every ns found. That's the simple case.
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.
There are 2 things here to consider potentially.

1) Locally scoped partner links may add types to our BPEL processes. Question
is, are they global or local (the types) with respect to variable declarations
in that or outer scopes. Can a higher scope use a type from that Partner
Link as it's type ? If the type system (and hence schema container,SC)
is global then yes. If no, that's another problem entirely. I don't think
the spec says anything about this and so for simplicity our impl here makes
the types global and hence visible from outer scopes as well.

2) Each PL can define schemas for a some NS, so let's assume I already
have ns1 in my schema container, that is  SC [ns1] != null. 
Assume now that a partner link definition adds some types in that namespace
ns1. From  a global perspective, I wanna say SC [ns1] = SC[ns1] +
newTypes. If newTypes does not affect any types currently defined in SC[ns1]
then I am ok. But what if some T1 in newTypes is effectively re-defining
a type in SC[ns1]?  Then either this redefinition is identical (in
which case it should be silently ignored) or warnings should be issued
or a n auto-magic pick should happen. Worse, what if M partner links effectively
re-define the types of a namespace and you have to then deal with the various
add/remove semantics of partner links ? (ie. if I add a link, i update
the global type system for a namespace, if I remove then I have to remove
some types from the effected namespaces, that gets a little tricky).

We have seen, however, that this is practically not always the case, that
types are added to several namespaces from several different locations
and hence the need to resolve such mess is ours and typically outside of
any model code API  that understands XML schema. Is eclipse model
API any more helpful here ?

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.

But imports are typically resolved by the XML schema model
code, because there are some inherent semantics to that, no ? In other
words, if I have a schema XML node and give it to such model code I would
get back say an XSDSchema which I could query for all the namespaces and
subsequently for the types within that namespace (that were imported).
But are there any provisions to deal with assembling a list of schemas
let's say, which you will have when you have more then 1 WSDL in your BPEL
process ? 

The approach we have taken is to have a concept of the schema container
indexed by a namespace which does use an underlying schema model API to
resolve the single schema nodes. But there is a fair amount of code to
stitch schemas together that come from the WSDLs that happens before being
handed off to the schema model API. 

I was just really curious if the eclipse SDK helped with this or not. 

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]

---

_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev

[attachment "michal.chmielewski.vcf"
deleted by James Moody/Ottawa/IBM]