Re: [wsbpel] Issue 24 - separate schemata for abstract and executableprocesses

[Danny van der Rijn <dannyv@tibco.com>]

while i don't have strong feelings about this, it seems to me that the
advantage you point out is also a disadvantage - it makes it (slightly)
harder to tell what kind of valid schema you have - is it abstract or
executable?  the question i have is which is the more prevalent use case?

will it be more often the case that i want to allow either abstract or
executable, or will it be more often the case that i want one or the other,
but not both?

comments?

----- Original Message ----- 
From: "Jim Clune" <jim.clune@parasoft.com>
To: "Danny van der Rijn" <dannyv@tibco.com>; "John Evdemon"
<jevdemon@microsoft.com>; <wsbpel@lists.oasis-open.org>
Sent: Monday, December 15, 2003 9:23 AM
Subject: Re: [wsbpel] Issue 24 - separate schemata for abstract and
executable processes


> I like the idea of introducing tighter type-checking by distinguishing
> between abstract and executable processes in the schema. However, I'm
> wondering if this would be more elegantly solved by disambiguating the
types
> where appropriate within a single schema. The current schema has a single
> top-level element definition named process of type bpws:tProcess. Perhaps
> this could be replaced by an xs:choice definition that has as its choices
> xs:elements of type bpws:tProcessAbstract and bpws:tProcessExecutable. A
> similar naming convention could be used for the activities, and elements
> that have identical constraints for the executable and abstract versions
> could use type names without the "Abstract" or "Executable" suffix.
>
> A potential advantage of this approach could be that validation can always
> be done against a single schema. This facilitates validation against a
> schema without knowing or determining first which type of process it is. A
> secondary benefit could be that it encourages reusing a single type
> definition for both versions where appropriate. Of course, the latter
> benefit is a weaker one because it could also be achieved by having three
> schemas: an abstract version, an executable version, and a base version
that
> both the others import.
>
> Jim Clune
> Parasoft Corporation          email: jim.clune@parasoft.com
> 101 E. Huntington Ave.      voice: (626) 256-3680
> Monrovia, CA.  91016           fax  : (626) 305-9048
> ----- Original Message ----- 
> From: "Danny van der Rijn" <dannyv@tibco.com>
> To: "John Evdemon" <jevdemon@microsoft.com>; <wsbpel@lists.oasis-open.org>
> Sent: Friday, December 12, 2003 9:01 PM
> Subject: Re: [wsbpel] Issue 24 - separate schemata for abstract and
> executable processes
>
>
> > yes.  that was the issue i raised.  and then yaron pointed out that once
> > separated, the schemata should be published as well.
> >
> > danny
> >
> > ----- Original Message ----- 
> > From: "John Evdemon" <jevdemon@microsoft.com>
> > To: "Danny van der Rijn" <dannyv@tibco.com>;
<wsbpel@lists.oasis-open.org>
> > Sent: Friday, December 12, 2003 5:21 PM
> > Subject: RE: [wsbpel] Issue 24 - separate schemata for abstract and
> > executable processes
> >
> >
> > On Friday, December 12, 2003 4:32 PM, Danny van der Rijn wrote:
> > >
> > > while the current schemas were published, the current document still
> > has the
> > > schemas, i believe.  and the current schemas don't provide separate
> > schemas
> > > for abstract and executable processes.
> > >
> > > if i'm showing the effects of jet lag, please let  me know..
> > >
> > I think the schemas should remain in the spec (appendices) _and_ be made
> > available as separate files (as they are now).
> >
> > The current spec doesn't use separate schemas for abstract and
> > executable processes - isn't this one of the reasons you raised issue #
> > 24?
> >
> > John
> >
> >
> >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the
> > OASIS TC), go to
> >
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
> >
>