Re: [wsbpel] Issue - 152 - New Proposal to Vote - Friendly Amendment

["Yaron Y. Goland" <ygoland@bea.com>]

I meant my proposal to be a friendly amendment to Paco's proposal. I did 
not intend to imply that it would be considered 'friendly' by anyone 
else. I apologize for any confusion.

As for what other groups have done, I would suggest that you may not 
like where a precedent based line of reasoning leads as one can make 
equally compelling precedent based arguments about massive numbers of 
shipping and soon to be shipping units that support a standard other 
than the one you favor. I would humbly suggest that you carefully 
consider if it is in your own interests to introduce a precedent based 
argument.

I would also point out that my friendly amendment to Paco's proposal 
would enable one to add attributes to the service-ref wrapper and that 
the resolution to issue 92 will introduce a mechanism to BPEL to declare 
when an extension is mandatory. The combination of these two features 
would enable one to implement the reference scheme functionality as an 
extension to BPEL.

		Yaron


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:
>  >
>  >>
>  >>
>  >>
>  >>
>  >> Following up on yesterday's discussion I am proposing an alternative
>  >> resolution to issue 152. The aim, as it was discussed, is to
>  >eliminate
>  >> unnecessary and redundant syntax:
>  >>
>  >> The "reference-scheme" attribute will be removed from the
>  >> "bpws:service-ref" element wrapper. The schema definition for the
>  >> wrapper will thus be changed to the following:
>  >>
>  >> <xs:element name="service-ref" type= tns:ServiceRefType />
>  >> <xs:complexType name="ServiceRefType">
>  >>     <xs:sequence>
>  >>         <xs:any namespace="##other" processContents="lax"
>  >> minOccurs="1" maxOccurs="1"/>
>  >>     </xs:sequence>
>  >> </xs:complexType>
>  >>
>  >>
>  >> Paco
>  >>
>  >>
>  >> To unsubscribe from this mailing list (and be removed from
>  >the roster
>  >> of
>  >> the OASIS TC), go to
>  >>
>  >http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/lea
> ve_workgroup.php.
>  >
>  >
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
> oup.php.
> 
>