[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82.1 - proposal to vote (directional vote)
Back to the two namespace issue: 1) If we want a schema for AP that also includes the idea of omission-shortcut, then the difference between AP and EP is quite big and two NSs probably make a lot more sense. 2) If we only validate AP after opaque-omission is removed (ie: after plugging in opaque tokens), then the difference is very small and so we probably don't need two NSs. I'm lost at the third position, which is taken in the proposal: Only validate after plugging in opaque, AND have two NSs. If we're going to go through the trouble of two NSs, then we might as well make the schema of the base properly in line with the resolution of 82, and allow validation without the extra step of replacing omitted things with opaque='yes'. Alex Yiu wrote: > > +1 to Charlton. > > Regards, > Alex Yiu > > > Charlton Barreto wrote: > >>Abstract and Executable BPEL have distinct and different syntaxes. While >>there are similarities between the two, they are not the same. >> >>I agree that the important issues are usability and schema design and >>maintenance. For these reasons, we should not force Abstract and Executable >>BPEL into a single namespace. Doing so would only complicate and confuse >>usage, while making the schema design and maintenance problematic. >> >>On the other hand, assigning each its own namespace will only serve to >>maintain clarity in use and description, and make it easier to keep them >>distinct from one another, simplifying schema design and maintenance. >> >>-Charlton. >> >>On 30.11.05 13:31, "Francisco Curbera" <curbera@us.ibm.com> wrote: >> >> >> >>>How "different" abstract and executable are is probably a matter of >>>subjective perception. I happen to think that with the resolution of issue >>>82 we have made it clear abstract semantics are based on executable >>>semantics so they cannot be that different. The real important issues are >>>the usability of the resulting language(s) and XML Schema design and >>>maintenance. >>> >>>Paco >>> >>> >>> >>> >>> Alex Yiu >>> <alex.yiu@oracle. To: Rania Khalaf >>><rkhalaf@watson.ibm.com> >>> com> cc: Charlton Barreto >>><cbarreto@adobe.com>, Ron Ten-Hove >>> <Ronald.Ten-Hove@Sun.COM>, >>>wsbpeltc <wsbpel@lists.oasis-open.org>, Alex Yiu >>> 11/30/2005 11:52 <alex.yiu@oracle.com> >>> AM Subject: Re: [wsbpel] Issue >>>82.1 - proposal to vote (directional vote) >>> >>> >>> >>> >>> >>> >>>Rania, >>> >>>Maybe I could refine what charlton said a little bit ... I would say: >>>Abstract and Executable Process are two very different and distinct >>>aspects of BPEL specification. That is why we need to spell out their >>>differences at the very beginning of Introduction section. >>> >>>Also, their syntax rules are totally different. Please recall that: XML >>>and XMLNS usage of source code language in BPEL spec are mainly for >>>syntax validation. >>> >>>One more important point to add: Different XMLNSes do not imply that XML >>>constructs of different XMLNSes are two disjoint language. Currently, >>><partnerLinkType> and <propertyAlias> are under another NS, not the main >>>BPEL source code NS. They are definitely considered as an integrated >>>part of BPEL specification and language. >>> >>>Thanks! >>> >>> >>>Regards, >>>Alex Yiu >>> >>> >>> >>>Rania Khalaf wrote: >>> >>> >>> >>>>Hi Charlton, >>>> >>>>This is exactly the misconception I was hoping to avoid. >>>> >>>>I refer to the 'two distinct languages' note below. One is simply a >>>>partial view on the other, with the common parts having the same >>>>semantics. >>>> >>>> >>>> >>>>Charlton Barreto wrote: >>>> >>>> >>>> >>>>>+1 to Alex and Ron. Abstract and Executable BPEL represent two >>>>>distinct languages, each with its own syntax. Each ought to be >>>>>described by its own schema, and thus belong to its own namespace. >>>>> >>>>>------------------------------------------------------------------------ >>>>>*From:* Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] >>>>>*Sent:* Tuesday, November 29, 2005 1:44 PM >>>>>*To:* Rania Khalaf >>>>>*Cc:* 'wsbpeltc' >>>>>*Subject:* Re: [wsbpel] Issue 82.1 - proposal to vote (directional vote) >>>>> >>>>>Rania, >>>>> >>>>> I have to disagree about using a single name space. Although the >>>>>abstract and execution languages are similar, they are *not *the >>>>>same. Forcing them into the same name space will be confusing, and >>>>>make existing schema-aware tools less useful, since will have to >>>>>depend on semantics where simple syntax could have sufficed. >>>>> >>>>> We shouldn't dismiss dual schemata as as impractical. There are >>>>>several approaches to this that avoid the horrors of >>>>>cut-and-paste.Other TCs have tackled similar problems; I'm sure this >>>>>TC can as well. >>>>> >>>>>-Ron >>>>> >>>>>Rania Khalaf wrote: >>>>> >>>>> >>>>> >>>>>>Hi Alex, >>>>>> >>>>>>I think going with the second point, that it doesn't make much sense >>>>>>to split the namespaces. Especially, as Yuzo had mentioned, that >>>>>>most tools don't support advanced XSD features and as Danny also >>>>>>said if there's no really compelling reason to manage several XSDs >>>>>>and changes we should try to keep it simple. >>>>>> >>>>>>As for cut and paste, the ns decl is up top anyway, so in many cases >>>>>>a cut and paste is just that and people will be able to copy bits >>>>>>with opaque in them. >>>>>> >>>>>>my .02. >>>>>>rania >>>>>> >>>>>>Alex Yiu wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>I think we should still have distinct namespaces between Abstract >>>>>>>and Executable BPEL, after most of 82.* got resolved. Major reasons >>>>>>>are: >>>>>>> >>>>>>> * There are _significant amount of syntax differences_ between an >>>>>>> Abstract Process with _opacityOmissionUsed="yes"_ and Exec >>>>>>> Process. (I am talking about the Abstract base, not AP11 >>>>>>>profile; >>>>>>> essentially all compulsory element and attributes becomes >>>>>>>optional.). >>>>>>> * On the other hand, there are _moderate amount of syntax >>>>>>> differences_ between an between an Abstract Process with >>>>>>> _opacityOmissionUsed="no"_ and Exec Process. (I already capture >>>>>>> those differences in my previous email). >>>>>>> * I am worrying people uses _copy-and-paste and mix-and-match >>>>>>> between Abstract and Executable BPEL_. (e.g. copying a >>>>>>>fragment of >>>>>>> empty <scope> from an Abstract BPEL into Exec BPEL). If we >>>>>>>use the >>>>>>> same namespace for both kinds of BPEL, it would be difficult for >>>>>>> us to tell that users are doing this kind of mistakes. If we use >>>>>>> different namespace, if people use an XML-aware tool to do >>>>>>>such a >>>>>>> copy-and-paste, we can detect that kind of mistakes more easily. >>>>>>> * With both AP11 and Template profiles, I tend to forseee people >>>>>>> would create the Executable Process based on Abstract Process >>>>>>>with >>>>>>> sometool help, given with constraints specified in the profile. >>>>>>> Even when people want to create an Executable BPEL based on >>>>>>> Abstract BPEL with just emacs/notepad. People just need to >>>>>>>following: >>>>>>> 1. copy the BPEL file >>>>>>> 2. _make one-line of change_: changing XMLNS declaration from >>>>>>> Abstract to Exec BPEL. >>>>>>> 3. add extra BPEL constructs for Execution Completion. >>>>>>> >>>>>>> Having two distinct namespace will allow us to >>>>>>>_validate the >>>>>>> Exec BPEL code during step (3) by using XSD_. Hence, >>>>>>>having >>>>>>> multiple NS gives us more tool to do BPEL validation, >>>>>>>while >>>>>>> collapsing Abstract and Executable do not yield any user >>>>>>> benefits. >>>>>>> >>>>>>> >>>>>>>Thanks! >>>>>>> >>>>>>> >>>>>>>Regards, >>>>>>>Alex Yiu >>>>>>> >>>>>>> >>>>>>> >>>>>>>Peter Furniss wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>I thought we said (or maybe it was just me) that we should revisit 24 >>>>>>>>once we had sorted out (in 82.*) just how much difference there was >>>>>>>>between syntax e and syntax a. When issue 24 was resolved we were >>>>>>>>anticipating a quite different scale of differences. I had to >>>>>>>>drop out >>>>>>>>of active involvement in 82 soon after that, I do think we should >>>>>>>>consider rescinding 24 (sorry Diane) >>>>>>>> >>>>>>>>Peter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: Rania Khalaf [mailto:rkhalaf@watson.ibm.com] Sent: 22 >>>>>>>>>November 2005 16:28 >>>>>>>>>To: Alex Yiu >>>>>>>>>Cc: wsbpeltc; Rania Khalaf; Danny van der Rijn; Ron Ten-Hove; >>>>>>>>>'Monica J. Martin' >>>>>>>>>Subject: Re: [wsbpel] Issue 82.1 - proposal to vote (directional >>>>>>>>>vote) >>>>>>>>> >>>>>>>>> >>>>>>>>>Hi guys, >>>>>>>>> >>>>>>>>>If we agree about the schema of abstract will only add the opaque >>>>>>>>>tokens then I don't see any motivation any more for 24's >>>>>>>>>resolution . >>>>>>>>> >>>>>>>>>Is it really worth all the pain of xsd:redefine and managing >>>>>>>>>three schemas instead of just saying in the text that you can >>>>>>>>>only use abstract tokens in AP ? >>>>>>>>> >>>>>>>>>regards, >>>>>>>>>Rania >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>To unsubscribe from this mail list, you must leave the OASIS TC that >>>>>>generates this mail. You may a link to this group and all your TCs >>>>>>in OASIS >>>>>>at: >>>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>>> >>>>>> >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe from this mail list, you must leave the OASIS TC that >>>>generates this mail. You may a link to this group and all your TCs in >>>>OASIS >>>>at: >>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe from this mail list, you must leave the OASIS TC that >>>generates this mail. You may a link to this group and all your TCs in >>>OASIS >>>at: >>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>> >>> >>> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]