[sca-bpel] New Issue - Removal of XPath 1.0 query language constraint on implementationRef attriibute.

["Najeeb Andrabi" <nandrabi@tibco.com>]

TARGET: SCA Client and Implementation Model Specification for WS-BPEL
(sca-bpel-1.1-spec-cd-01-rev13.doc)

DESCRIPTION: Section 2.6 "Hand-Generated Component Type Files" (in the
Nov
20 TC call renamed to "Component Type Side Files") puts a constraint on
the implementationRef attribute to always use XPath 1.0 as the query
language. This restricts forward mobility of the "SCA client and
Implementation Model Specification for WS-BPEL" as it requires that if
XPath 2.0 becomes the defacto standard for query languages or a new
query language emerges, an update or a new version of this specification
has to be released. 

PROPOSAL: Change implementationRef attribute to an element that defines
an attribute for the query language used. The schema for this element
will be similar to the query element defined in WS-BPEL 2.0
specification. 

Change text in section 2.6 so that it describes implementationRef as an
element rather than as an attribute. 

Change 

"The corresponding partner link is determined by either the value of the
sca-bpel:implementationRef attribute or the value of the name attribute,
if no sca-bpel:implementationRef attribute is present.The
@sca-bpel:implementationRef attribute MUST contain a valid XPath 1.0
expression, which when executed on a BPEL process returns exactly one
<partnerLink> element. The partnerLink thus identified will be
considered to correspond to the service or reference that contained the
@sca-bpel:implementationRef attribute. If a service or reference does
not have an @sca-bpel:implementationRef attribute, then it will act as
if it had @sca-bpel:implementationRef=//partnerLink[@name="{name}"],
where {name} is the value of the @name attribute of that service or
reference."

to

"The corresponding partner link is determined by either the value of the
sca-bpel:implementationRef element or the value of the name attribute,
if no sca-bpel:implementationRef element is present.
sca-bpel:implementationRef element provides the ability to override the
default query language. sca-bpel:implementationRef element MUST support
the use of [XPath 1.0] as the query  language. XPath 1.0 is indicated by
the default value of the queryLanguage attribute, which is:
	urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0 which represents
the usage of XPath 1.0 within WS-BPEL 2.0.

The @sca-bpel:implementationRef element MUST contain a valid query in
the specified query language, which when executed against the BPEL
<process> returns exactly one <partnerLink> element. The partnerLink
thus identified will be considered to correspond to the service or
reference that contained the sca-bpel:implementationRef element. If a
service or reference does not have an sca-bpel:implementationRef
element, then it will act as if it had an element having a value in
default XPath 1.0 expression language
<sca-bpel:implementationRef>//partnerLink[@name="{name}"]</sca-bpel:impl
ementationRef>, where {name} is the value of the @name attribute of that
service or reference. "


Change schema in Section 5.A XML Schemas "XML Schema for SCA-BPEL
Extensions of WS-BPEL 2.0"

<attribute name="implementationRef" type="xsd:string" /> 

to 

<xsd:element name="implemetationRef" type="sca:tImplementationRef"/> 
 <xsd:complexType name="tImplementationRef" mixed="true"> 
   <xsd:sequence> 
       <xsd:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/> 
   </xsd:sequence> 
   <xsd:attribute name="queryLanguage" type="xsd:anyURI" default=
"urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"/> 
   <xsd:anyAttribute namespace="##other" processContents="lax"/> 
 </xsd:complexType>  
</xsd:element>


Also, the SCA Liaison subcommittee should push for adopting this query
language scheme across the C+Is.