Hi, Mark,
I think Michael Rowley's proposal has some misnomer issue (BPEL
terminology vs common programming terminology). That creates some
misunderstanding that I had and you are having (I guess). Where
"expression" is used, I think Michael means to refer to generic form of
from spec.
Please see the email thread between Michael and me in Nov.
A fragment of my email:
May I suggest the following wording changes,
which would be more
consistent to BPEL's terminology usage? (For example, "expression" is a
formal term in BPEL as one of variants of from-spec). I think that
partially caused some confusion on my side.
“If the
variable has an
initialization from-spec
then that becomes the default value for the variable in cases where the
SCA
component does not provide a value for that property. If a value is provided for the property,
the initialization from-spec is not
evaluated.
If the
from-spec is a literal
value, where it has the following form:
<from><literal>literal value</literal></from>
then
the literal value
will be represented as the default value in the component type for the
process.
Any other kind of initialization from-spec
will not be represented in
the component type. However, even though the other kinds of
initialization from-spec are not
represented in the component type, they
would still be computed and used as the default value for the property
when the
component does not provide a value for that property.”
After
your clarification, the last "however" sentence seems to become
optional. I have no strong opinion on whether to keep it or not.
However, I think that Michael does want to treat literal variant of
from-spec differently. And, that I need to chew on it further.
Thanks!
Regards,
Alex Yiu
Mark Ford wrote:
I'm a little confused as to the
purpose of default-property-value in the assembly spec. Is this value
supposed to convey what the default is within the implementation if no
value is provided by the configuration? If this is the case, then I
agree with Najeeb and I better understand Michael Rowley's desire to
treat expressions differently than literals.
However, it's not clear to me
that this is what the default-property-value is supposed to convey. My
first reading of it was that it was the value used if the composite
didn't supply a value and not necessarily a value that was introspected
from the implementation.
From: Najeeb
Andrabi [mailto:]
Sent: Wednesday, December 12, 2007 2:45 PM
To: Michael Rowley
Cc:
Subject: RE: [sca-bpel] Issue 11 - BPEL variable
initialization and SCA properties
Hi Michael,
I think it impossible to
determine which initialization expression initializes the variable in
case of complex BPEL process having conditional/concurrent flows with
multiple initialization expression of the same variable. In my view, we
should state that “if the literal value can be determined by static
analysis of the process then it will be represented as the default
value in the component type for the process”
Thanks,
Najeeb
From: Michael Rowley
[mailto:]
Sent: Wednesday,
December 12, 2007 9:29 AM
To: Mark Ford; Alex Yiu
Cc:
Subject: RE:
[sca-bpel] Issue 11 - BPEL variable initialization and SCA properties
The key
question, for me, is whether the component type should show non-literal
default values. Imagine reading a component type definition that looks
like this:
<componentType>
<property name=”x” defaultValue=”$y”/>
</componentType>
In this
example, I’m assuming that BPEL had an initialization expression for
“x” that assigns it to the value of the “y” BPEL variable. If you copy
this into the component type, the component type makes no sense,
because there is no way to resolve “y”.
That is why
I said that only literals can be used by the component type of a BPEL
process.
Michael
From: Mark Ford
[mailto:]
Sent: Tuesday,
December 11, 2007 7:53 PM
To: Michael Rowley; 'Alex Yiu'
Cc:
Subject: RE:
[sca-bpel] Issue 11 - BPEL variable initialization and SCA properties
The
mustSupply text from the assembly specification below SHOULD use the
capitalized words from RFC 2119. It would be better to say that the
default-property-value MUST NOT be provided when mustSupply="true".
That said I
think the treatment of BPEL variable initialization should be the same
regardless of the form of the from-spec. If I understand your proposal,
you would treat an expression from-spec differently than a literal
from-spec.
After
reviewing the Assembly spec a little, I'm inclined to suggest that any
value from the component overrides the initialization from-spec for the
variable in the BPEL. This seems consistent with the goal of allowing
the configuration of an implementation with externally set data values.
(Section 6.1 of the Assembly spec).
- Mark
From: Michael Rowley [mailto:]
Sent: Thursday,
November 01, 2007 5:58 PM
To: Alex Yiu; Mark Ford
Cc:
Subject: RE:
[sca-bpel] Issue 11 - BPEL variable initialization and SCA properties
I looked at
the Property section of the Assembly Specification. It looks like what
is there is OK. Here it is:
mustSupply
(optional) – whether the property value must be
supplied by the component that uses the implementation – when
mustSupply="true" the component must supply a value since the
implementation has no default value for the property. A
default-property-value should only be supplied when mustSupply="false"
(the default setting for the mustSupply attribute), since the
implication of a default value is that it is used only when a value is
not supplied by the using component.
It says
that a default value should be only be supplied when mustSupply is
false, but it _doesn’t_
say that a default value MUST be supplied.
Perhaps we
could add the following to the SCA BPEL spec at line 357 (in the
paragraph that describes the meaning of sca:property=”yes”):
“If the
variable has an initialization expression (a from-spec) then that becomes
the default value for the variable in cases where the SCA component
does not provide a value for that property. If a value is provided for the property,
the expression is not evaluated. If the from-spec is a literal value,
where it has the following form:
<from><literal>literal value</literal></from>
then the
literal value will be represented as the default value in the component
type for the process. Any other kind of initialization expression will
not be represented in the component type.”
Michael
-----Original
Message-----
From: Alex Yiu [mailto:]
Sent: Tuesday, October 16, 2007 2:30 PM
To: Mark Ford
Cc: ;
Subject: [sca-bpel] Issue 11 - BPEL variable initialization and SCA
properties
Issue
entered.
http://www.osoa.org/jira/browse/BPEL-11
Regards,
Alex Yiu
Mark Ford
wrote:
>
TARGET: SCA Client and Implementation Model Specification for WS-BPEL
>
> TITLE:
BPEL variable initialization and SCA properties
>
>
DESCRIPTION: Is the target variable allowed to have an initialization
>
defined within the BPEL process and if so, is this initialization
ignored?
> It
seems like the initialization should be allowed but not executed in the
> case
where a process is packaged as an SCA and the property is provided by
> the
component. It's probably also worth pointing out that the variable must
> be an
element or type variable. Message variables cannot be initialized by
> an SCA
property.
>
>
>
