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] wsbpel 3/30/2006: Extensibility Reference (Section 5.3)



> yiu: Hi, Monica and Danny,
>
> Section 8.3 is not talking BPEL extensibility per see. It is talking 
> how BPEL makes use of XPath extension function. But, it does not hurt 
> to add a reference to Section 5.3 in Section 8.3.

mm1: I can open an action item, but would like to finish the discussion 
below before doing so. Action Item: Add a reference to Section 5.3 in 8.3.

> yiu: On the other hand, I think we may also want to explicit call out 
> that in Section 8.3:
> * WS-BPEL processor may make XPath extension function of other NS 
> available. 

mm1: This may beg more discussion Alex (if we consider may is MAY).  We 
explicitly call this out in the BPEL namespace in this section. I'm not 
advocating either way but asking the question.

> * The <extension> declaration does NOT cover those XPath extension 
> functions and they must be always understood by WS-BPEL processor. If 
> unrecognized XPath function is used and if it is detected by static 
> analysis, the process defintion must be rejected. 

mm1: We do say this must (MUST) be supported and, as a mandatory 
standard extension, the process definition would be rejected (as 
specified in Section 5.3). That's covered. Yet, do we need more 
discussion about unrecognized XPath functions and those from another 
namespace?

> * The XPath extension, as always required by XPath semantics, MUST not 
> perform any side-effect operation visible to the WS-BPEL process.

mm1: We touched on this at the F2F, so should we open an issue. We 
didn't choose to apply rigor to the language when it was discussed Friday.

> The last bullet is important to add because a lot of XPath users 
> presume otherwise. In the javadoc of (javax) XPath function object, 
> similar no-side-effect caution is called out as well.
>
> (Since the above are already mentioned in other parts of BPEL spec or 
> implied by other specifications, I don't consider a normative change. 
> An Action Item would be good enough, IMHO).
>
> Regards,
> Alex Yiu
>
>> vanderRijn: An interesting thought.  5.3 is currently about how to 
>> extend BPEL, not how BPEL extends XPath (or WSDL).  I could see 
>> having it do that, but otoh, it's not inconsistent or incomplete as 
>> it is.
>>
>> Just my $0.03 (adjusted for fed rate hikes)
>> Danny
>>
>>> mm1: In Section 8.3, we discuss these standard extensions: "The 
>>> following
>>> XPath extension functions are defined by WS-BPEL and MUST be supported
>>> by a WS-BPEL implementation:
>>>
>>> ·        getVariableProperty, described below
>>>
>>> ·        doXslTransform, described in section 8.4. Assignment
>>>
>>> These extensions are defined in the standard WS-BPEL namespace."
>>>
>>> Do we also need to mention these in Section 5.3 on  Language
>>> Extensibility? If so, I can open an action item. Thanks.
>>>



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