[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)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]