[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 82.1 - questions about bullets in proposal.
Hi Rania, I am glad that the conversation of this thread is becoming a technical discussion again, rather than a religion-like argument. Thank you very much for steering to that direction. :-) For 1), "opacityOmissionUsed" has not been in a formal proposal yet in any previous 82.* proposal. "opacityOmissionUsed" is added based on the other email thread between you and me (around Nov 8). You were suggesting instead of duplicating chunks of schema for opacity omission: let's assume people (implementing Abs BPEL) inject those omitted opacity first before submitting it to schema validation. I expressed that I am OK with that idea. Instead of asking a profile-independent Abstract BPEL implementation guessing whether it needs to do such an injection based on profile URI, let's mark the abstract profile explicitly. That's the reasoning behind this "opacityOmissionUsed" attribute. For 2), Your suggestion makes sense. I should make a reference to Issue 107. On the other hand, 'createInstance' is a normative bug fix that I want to use Issue 82.1 to fix Issue 107 resolution. Recently, we realized that we cannot use opaqueActivity to model a start activity, if "createInstance" is not available. So, that is a real bug in Issue 107 resolution and we need to fix this. For "the third bullet about expressions omits a few (condition of 'while' , etc)" ... those are just examples, in this direction vote, not exhausive list. :-) The exhausive list will show up in the final proposal to vote for this issue. For 3) and 4), I will try to discuss them further in the other email thread. Thanks! Regards, Alex Yiu Rania Khalaf wrote: > Hi guys > > I have some very specific questions about parts of the directional > proposal: > > 1) The opacityOmissionUsed came up in the discussion for 82, but was > not included in the resolution nor was it in the . I don't recall > whether we agreed to move it to this issue and the section in the > resolution on 'open issues after resolution of 82' doesn't mention it > although the e-mails did raise it for discussion. So I am assuming > that means it was not accepted ? Am I missing some e-mails where we > agreed to move it to 82.1 ? Or are you proposing it newly here again ? > > 2) The third bullet child of the second bullet, about the 3 kinds of > opaque constructs, should just say 'the opaque constructs are those in > 107' - Otherwise, we'll be dealing with two places defining 107 and > that'll be a mess to keep track of. For example, the first bullet is > actually incorrect ! The 'createInstance' attribute is NOT allowed on > <opaqueActivity> (see 107, 99). The third bullet about expressions > omits a few (condition of 'while' , etc). > > 3) can you please explain more about the rational behind the three > schema design instead of deriving the AP schema from the EP schema ? > I'm not against any of them, I just want to understand the motivation > especially since the text talks about AP as derived from EP so that > seemed more natural.. > > 4) i still have a couple of questions about the two namespace idea, > but I will put those in a separate e-mail to follow up with that > discussion > > > > Alex Yiu wrote: > >> >> Hi, all, >> >> Here is the summary of direction on how Abstract and Executable >> Process differ syntax-wise and how XSD would be applied to capture >> those differences: >> >> * As per Issue 24 resolution, there will be two namespaces: one for >> executable; one for abstract >> * For abstract process: >> o a required URI-type "*profile*" attribute at <process> >> element >> o a required "boolean"-type ("yes"/"no") >> "*opacityOmissionUsed*" attribute at the <process> element: >> It indicates whether opacity omission is used. (See more >> details below in "How XML Schemas are applied") >> o Introducing 3 kinds of opaque constructs: >> + opaque activity: <opaqueActivity>: its structure would >> be similar to an <empty> activity but with an >> additional "createInstance" attribute >> + opaque attribute value: "##opaque": that will be >> allowed to be used in almost any existing BPEL >> attribute construct (include ones based on NCNAME, >> QNAME, URI, and etc). >> + opaque expression: e.g. the opaque version of >> from-spec: <from opaque="true" /> and condition >> expression used in "if-then-else". * For >> executable process: >> o All 3 kinds of opaque constructs are disallowed. >> o There will be no "profile" or "opacityOmissionUsed" >> attributes at the <process> level. >> * How XML Schema are applied: >> o Usage of "*opacityOmissionUsed*": >> + This required attribute indicates whether opacity >> omission is used in the Abstract Process. >> + If opacityOmissionUsed is set to "yes", a WS-BPEL >> processor may (intentionally lower case) need to add >> opacity token first before attempting to use the XML >> Schema for Abstract Process to validate the XML source >> of the abstract process. Without adding opacity tokens >> first, the Abstract Process may be deemed to be >> invalid according to Abstract Process schema. >> + If opacityOmissionUsed is set to "no", opacity >> omission MUST NOT be used in the abstract process. >> + The Abstract Process schema does not attempt make >> constructs required by Executable Process optional. >> Instead, it makes opaque construct available to fill >> in those undecided details required by Executable >> Process. >> + Examples: >> # An empty sequence of this form: >> <sequence /> >> MAY be used within an A.P. with >> opacityOmissionUsed set to "yes" only, while the >> following form of sequence MAY be used within >> an. A.P. regardless of its opacityOmissionUsed >> value: >> <sequence> <opaqueActivity /> </sequence> >> # A variable declaration of the this form: >> <variable name="varX" /> >> MAY be used within an A.P. with >> opacityOmissionUsed set to "yes" only, while the >> following form of variable declaration MAY be >> used within an. A.P. regardless of its >> opacityOmissionUsed value: >> <variable name="varX" element="##opaque" /> >> o XML Schema files: we would attempt an XML-schema approach >> which avoids massive grammar definition duplication, as >> described below: + The current main BPEL >> XSD file will be spilt into 3 >> pieces: >> # wsbpel_common_main.xsd: which serve as the >> common base of BOTH executable and abstract >> process. It will not have a targetNamespace. >> # wsbpel_exec.xsd and wsbpel_abstract.xsd: These >> two XSD files will have their own >> targetNamespace (one for executable, one for >> abstract). These XSD files will reuse the >> definition of BPEL grammar from >> wsbpel_common_main.xsd by <xsd:redefine>. The >> delta between abstract and executable BPEL will >> be captured within the <xsd:redefine> section of >> these XSD files. >> >> >> >> Thanks! >> >> >> Regards, >> Alex Yiu >> >> > >