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