[changing subject to include issue #]
As we discussed on the call, we need to do 2 things:
1 - decide what it is we actually want the spec to require here
2 - come up with language that specifies that
IMO it will be much easier to do #1 if we don't do #2 at the same
time. I'll take a stab at what
it is we want to do, using an illustrative (and pathological) example.
Imagine a process with the following (scopes and) partnerLinks:
Scope1
shipping
_shipping_2
receiving
_receiving_2
Scope2
_shipping_1
_receiving_1
As context, here's section 2.3:
"It is possible to declare partner links local to a <scope>
in WS-BPEL, besides
declaring partner links at the <process>
level. The names of partner link declared in different <scope>
could potentially share the identical name. [SBPEL2019] When
multiple partner links share the same name, the scheme defined by [SBPEL2020]-[SBPEL2022]
MUST be used
to disambiguate different occurrences of partner link declaration.
·
Let "originalName"
be the original NCName used in multiple partner link declarations.
·
[SBPEL2020] The
introspected component
type MUST include services or references corresponding to these partner
links
with names: "_orginalName_1"
to "_orginalName_N".
Whether the partner
link corresponds to a service or reference does not affect the name
used. [SBPEL2021]
The number suffixes for the partner links MUST be based on the lexical
order of
the corresponding partner link occurrences in the process definition.
·
[SBPEL2022] If any "_orginalName_i"
(where 1 <=
i <= N) is already the name of a partner link declaration in the
process
definition, additional underscore characters MAY be added at the
beginning of
all aliases consistently to avoid collision."
I read the above rules as resulting in the following:
Scope1
shipping <- _shipping_1
_shipping_2 <- __shipping_2_1
receiving <- _receiving_1
_receiving_2 <- __receiving_2_1
Scope2
shipping <- _shipping_2
receiving <- _receiving_2
_shipping_1 <- __shipping_1_1
_receiving_1 <- __receiving_1_2
Note: This solution is not handled in a single-pass. Would a
single-pass solution be preferable?
I'm not sure that this is the prettiest solution, but then again, I'm
not sure I care. I'd welcome other solutions, as well as other
interpretations of the text. However, all that is truly important,
IMO, is that we agree on what we want (#1) and then do our best to
encode it (#2). If #2 proves too difficult for our decision on #1,
then I propose we change #1.
Danny
Danny van der Rijn wrote:
If you're going down to this level of detail, I think you need to be
more explicit about what "recursive" and (where 1 <= i <= N)
mean. Something like
"If any "_originalName_i" (where N is the number
of partnerLinks of name 'originalName', 1 <= i <= N) is
already the name
of a partner link declaration in the process definition, then the smallest number of additional
underscore characters MAY
MUST be added at
the beginning of all aliases originalNames, consistently to
avoid collision, to avoid a collision."
Anish Karmarkar wrote:
Title:
SBPEL2022 has an incorrect 'MAY' and is not applied recursively
Target: SCA BPEL C&I PR 01
Description:
SBPEL2022 states the following:
"If any "_orginalName_i" (where 1 <= i <= N) is already the name
of a partner link declaration in the process definition, additional
underscore characters MAY be added at the beginning of all aliases
consistently to avoid collision."
'MAY' here means that some runtimes may not choose to do this. We want
deterministic names that are independent of the runtime.
It is also possible that after an additional underscore is added at the
beginning it still results in a conflict. SBPEL2022 needs to be applied
recursive till there is no collision.
Proposal:
Replace SBPEL2022 with --
"If any "_orginalName_i" (where 1 <= i <= N) is already the name
of a partner link declaration in the process definition, then an additional
underscore characters MAY
MUST be added at
the beginning of all aliases names,
recursively, consistently
to
avoid collision, until a collision is
avoided."
(alternately, we can say something along the lines of "... additional
minimum number of underscore characters that results in no collision
MUST be added at the beginning of all names consistently."
-Anish
--
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
S/MIME Cryptographic Signature
