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 - 11 - Proposal (after off-line discussions)



Hi Alexandre,

To make some comments on the last two bullets:
  • Currently all BPEL variables are unqualified. Keeping global parameter unqualified for matching BPEL variables are good for simplicity and usability.
  • Yes, doXSLTransform() can be used in <while>, <repeatUntil>, transition condition and if-then-else as well. But, not in join condition (usage join condition is very restricted). Manifesting control-links, partnerLinks as XMLinfoset directly are not much for the TC to handle for this stage of spec cycle. On the other hand, I did have a proposal to manifest variable properties an a function [ e.g. foo:ssnProperty($customerRec) ]. But, I did not drum up enough support that. I marked as revisitable for next spec cycle.


Thanks!


Regards,
Alex Yiu


Alexandre Alves wrote:

Hi Ron,

 

The examples are very useful!

A couple of comments:

 

-          Considering that we are using XML info-set terminology, I was wondering if we should say ‘as the document element property of the source DII’ instead of ‘as the single child of the root node of the source tree’ when explaining the source node-set?

-          I was under the impression that XSLT variables and params are identified by a QName, so shouldn’t we name the BPEL variables as ‘bpws:foo’? Or was the rationality to keep the names unqualified for simplicity sake? The advantage of qualifying them using the BPEL URI would be that it avoid name clashes, wouldn’t it?

-          As doXslTransform is a xpath function, it can in theory be used in while condition expressions, join condition expression, until expression, etc. Is this allowed? If it is, shouldn’t we propagate BPEL links, partnerLinks, and properties, to the XSLT engine as well?

 

Also, although this is not relevant to this proposal in question, I think it is interesting to consider that the XUpdate committee has re-started its activities recently…

 

Best regards,

 




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