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