[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 152 - New Proposal to Vote - Friendly Amendment
|
+1. Like it or not, the EPR problem is not ours alone. Other TCs have had to address this issue, and barring extraordinary requirements that are peculiar to BPEL, we ought to harmonize our EPR solution with them. Otherwise the Tower of Babel beckons. -Ron Martin Chapman wrote: That's not friendly! Two other groups have adopted the proposal, including non-MD authors and backers, as a reasonable way to isolate the respective specs from underlying changes to addressing schemes. This is a mountain out of a mole-hill for what is just an optional attribute. Martin.-----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: 09 September 2004 01:40 To: Francisco Curbera Cc: wsbpel@lists.oasis-open.org Subject: [wsbpel] Issue - 152 - New Proposal to Vote - Friendly Amendment I would propose the following friendly amendment: <xs:element name="service-ref" type= tns:ServiceRefType/> <complexType name="ServiceRefType"> <complexContent> <restriction base="bpws:tExtensibleElements"> <sequence> <element ref="bpws:documentation" minOccurs="0" maxOccurs="unbounded"/> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="1"/> </sequence> <anyAttribute namespace="##other" processContents="lax"/> </restriction> </complexContent> </complexType> This will introduce two changes: 1) If an EPR can be fully described using nothing but attributes then it is possible to do so by not having any children in service-ref and instead defining the values as attributes on the service-ref element itself. 2) It allows for documentation elements. Since these elements belong to the BPEL controlled namespace there should be no confusion as to their meaning inside of an EPR. Yaron Francisco Curbera wrote: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]