OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - R40 - From/To Extensibility



Hi All,

[Note: I have communicated the following with Dieter already. I think he also agrees.]

<from>/<to> extensibility is already addressed in XSD. (See green)

================
    <xsd:complexType name="tFrom" mixed="true">
        <xsd:sequence>
            <xsd:element ref="documentation" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:choice minOccurs="0">
                <xsd:element ref="literal" minOccurs="1"/>
                <xsd:element ref="query" minOccurs="1"/>
            </xsd:choice>
        </xsd:sequence>
        <xsd:attribute name="expressionLanguage" type="xsd:anyURI"/>
        <xsd:attribute name="variable" type="BPELVariableName"/>
        <xsd:attribute name="part" type="xsd:NCName"/>
        <xsd:attribute name="property" type="xsd:QName"/>
        <xsd:attribute name="partnerLink" type="xsd:NCName"/>
        <xsd:attribute name="endpointReference" type="tRoles"/>
        <xsd:anyAttribute namespace="##other" processContents="lax"/>
    </xsd:complexType>
================

================
    <xsd:complexType name="tTo" mixed="true">
        <xsd:sequence>
            <xsd:element ref="documentation" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element ref="query" minOccurs="0"/>
        </xsd:sequence>
        <xsd:attribute name="expressionLanguage" type="xsd:anyURI"/>
        <xsd:attribute name="variable" type="BPELVariableName"/>
        <xsd:attribute name="part" type="xsd:NCName"/>
        <xsd:attribute name="property" type="xsd:QName"/>
        <xsd:attribute name="partnerLink" type="xsd:NCName"/>
        <xsd:anyAttribute namespace="##other" processContents="lax"/>
    </xsd:complexType>
================

If my memory is correct, we did not derive from "tExtensibleElements" directly because we would encounter those XSD grammar issue:
  • mixed="true": At "tExtensibleElements" is mixed="false". On the other "tFrom" and "tTo" needs mixed="true" to allow text to appear in the middle of element body. XSD Type derivation does NOT allow overridding of such a setting.
[We need to be carefully that we dont cause any infamous ambiguious XSD grammar issue during extension]

IMHO, we already explicitly design our XSD to allow the extensibility. We just need to explicitly clarify that in the spec text. Only editorial changes are needed. How about:

-------------------
Note: All variants of from-spec and to-spec are extensible in a fashion similar to other constructs defined in WS-BPEL.
-------------------


Thanks!


Regards,
Alex Yiu




ws-bpel issues list editor wrote:

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - R40 - From/To Extensibility

Status: received
Date added: 10 Nov 2006
Date submitted: 9 Nov 2006
Submitter: Dieter Koenig1
Description: Almost every WS-BPEL language element is extensible. The current specification defines a number of <from> and <to> element variants for the <copy> operation. The specification text in section 8.4. ("... MUST be one of the following variants: ...") excludes the extensibility of <from> and <to>. This is an unnecessary restriction. It forces every new variant of <copy> to be enclosed in an <extensibleAssignOperation> containing a new <copy> element which repeats the existing copy semantics in order to add different from-specs and to-specs.
Submitter's proposal: Make <from> and <to> elements extensible. That is, allow extension attributes and elements defined in other namespaces to appear within the <from> element and <to> element. The least invasive approach for the specification would be adding a new variant to the from-spec and to-spec. Note that the XML schema does not need to be changed as it already allows these extensions.

In 8.4., add a 6th variant to <from>:

   <from from-attribute-of-another-namespace*>
   from-element-of-another-namespace*</from>
  

and add a 5th variant to <to>:

   <to to-attribute-of-another-namespace*>to-element-of-another-namespace*
   </to>
  

Changes: 10 Nov 2006 - new issue

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - R40 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - R40 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]