OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue 82.1 - digging into details ...

Hi Rania, Satish and others,

I am trying to list out the syntactic difference between Abs and Exec BPEL:
1) allowing opaqueActivity
2) allowing opaque expression
3) allowing "##opaque" for attribute value
4) all required ref to activity becomes optional
   [e.g. whether a <scope> must contain an activity]
5) all required attribute becomes optional attribute ???
   [e.g. whether a <partnerLink> must have a name attribute]
   [Note: All "variable" attributes in msg activity are already optional 
even in exec BPEL
          because of optional <fromPart> and <toPart> features. ]
6) all required sub-elements becomes optional ???
   [e.g.: Whether there must be at least one <variable> under <variables>?
          Whether <if> must have a <then>?
      Whether <pick> must have at least one <onMessage>? ]

Do I miss other potential differences?

 From 1) to 4), the intended syntactic difference are very clear to me.
Those changes are relatively easy to achieve in terms of XSD if we 
decide to avoid duplication of XSDs. [ There are some technical 
challenges in the area of 3) ... ]

However, I am not 100% sure what we want out of 5) and 6). Because, it 
seems to me that in both profiles of 82.2 and 82.3 do not need that kind 
of "super flexible syntax" in Abs Process. (I have reviewed the "Base 
Language subset" of 82.3).

[ I intentionally separate 4) from 6).  82.3 definitely (observable 
behavior profile) is using 4) for sure.]

I want to bring that up is: if we go all the way of allowing this "super 
flexible syntax", virtually all the XSD types used in BPEL schema will 
be different between Abs and Exec BPEL. Hence, it forces virtually 
duplicating definition of every single BPEL construct. If we say "yes" 
to 5) and 6) all the way, then we may be better off just duplicating 
most of schema.

If we decide to go for the duplicating the schema, we may want to delay 
the actual work of Issue 82.1 until the exec BPEL schema got finalized. 
As of now, there are still at least a number of places where the schema 
are not consistent. E.g. <fromPart> and element-based, XSD-type-based 
message operation is not applied consistently to all message operations 

Please let me know what you guys feel.

Alex Yiu

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]