We have been having a few offline e-mails with James on this subject.
It was my oversight not to the list on this. Apologies.
Here is the
latest context for which you all can chime in.
James Moody wrote:
Michal Chmielewski
<michal.chmielewski@xxxxxxxxxx>
wrote on 06/21/2006 01:47:26 PM:
> James Moody wrote:
> > > The only other question is where is
a logical place to add an import
> > > of a schema file (WSDL imports can be added while
browsing
for
> > partner links).
> >
> > At the end of the browse, when the
dialog returns the appropriate
> > type, we create a command and execute
it. That command sets the type
> > of the variable. It should also add
an import at that time. This
> > will make undo work properly. Of
course, it would have to add the
> > appropriate "type" of import
depending on whether it was an XSD
> > type/element or WSDL message that
the user chose from the dialog.
> > Uhhh, cart before the horse ....
> >
> > The import has to exist before then can browse. No ?
>
> Nope. We can let the user browse
for anything in the world. When
> they pick something to use, we
insert the reference into the process
> and, at that time, create an import
for it. (It's certainly possible
> to do it the other way - i.e.
only let them browse for things that
> are imported, but that turns the
scenario around and forces people
> to create imports before they
actually choose things). The way I'm
> thinking, the import is just a
by-product of what the user's really
> trying to do, which is pick a
type. I realize both of these
> scenarios are perfectly valid,
but I personally think we get more
> value out of widening the browse
contents and then creating the
> imports afterward. I'd be interested
in your thoughts on this though.
> I somehow think being asked to select a type
of a variable means
> selecting a type from an existing "type system" = all imports
so
> far. You usually work within a certain domain of problems when
> orchestrating, so I would imagine that at some point, when all
> interested WSDLs and XSD are imported you will certainly want to
> browse just that set of types when declaring variables ...
>
> For example, before calling a service, you will create a partner
> link, which ought to import the WSDL and hence make included XSD
> types available. So when you are constructing an invoke and need
to
> prep a variable for the call, you will probably want to select
it's
> type from the existing imports. It's kinda like Java imports -
once
> you import the package/class you can write the code - the subset
of
> imports defines the set of things you work with in the given
class.
The Java analogy is a good one. In Eclipse,
though,
when you use code assist to pick a type, you can see *all* types on the
build path, regardless of whether or not you have imported them.
Selecting
one of them automatically inserts the import. I think this is one of
the
reasons why (although I couldn't articulate it at the time) I feel that
the import itself is secondary - in the JDT tools, it would feel kind
of
backwards if the user was made to author the import, and only after
that
could select the type. It seems kind of the same in BPEL for me - let
the
user pick any type we can see, and add the import for them (since the
import
is really only a mechanism - a means to an end).
OK I see this now. Some questions then:
1) Where would you retrieve the universe of types from that you are
talking about ?(the "build-path") ? Current project ? Open projects ?
Is there a concept of XSD Type path that we have to introduce?
2) Would WSDLs be included in this path as well ?
3) Transparent import is one thing but namespace-prefix mappings still
ought to be allowed.
Walking an open ended set of visible types or WSDLs might be time
consuming and an overkill though. I am still not convinced this is the
right way.
> My point was that partnerLink
definition in the
process will create
> the WSDL import, so we are OK here. But what defines the XSD
import
> ? So far, I have in the type selection dialog and extra button
that
> allows you to add an import (basically, the case where you don't
> have a particular types imported yet, but need them in the
process)
> but type selection happens only from the existing type system.
Does
> that make sense ?
>
> I think we are generally saying the same thing ...
>
> One other thing, and that's a little pesky issue. During import,
one
> would have to setup a namespace mapping for the import on the BPEL
> file for the import. Just as I feel we should keep the BPEL source
> clean on read/write cycles (DOM facade issue), I think we ought
let
> people re-map the namespace mappings on the BPEL file as well
since
> we can only create generic prefix mappings and some may feel a
need
> to make them more meaningful as the prefixes are used throughout
the
> code (in expressions for example).
>
> -michal
>
james
--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|
