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 250 - Proposal for Vote


Title: [wsbpel] Issue 250 - Proposal for Vote
Alex -

If the original wording caused you to understand it that way, then it does need to be changed.  However, your rewording doesn't match the intent of what Rania and I were working towards.


  • If we decide to make a normative change to ignore links within an extensionActivity that a WS-BPEL Processor does not understand. We should apply this ignore semantic consistently to all standard attributes and elements.

We weren't suggesting a normative change here.  We were pointing out resultant behavior. 

We weren't saying to ignore the links in an extensionActivity.  We were saying that if there's something like:
(syntax compressed for ease of my typing...)
<flow>
    <link name="crossesExtensionActivity"/>
   
    <receive>
       <source name="crossesExtensionActivity"/>
    </receive>

    <extensionActivity>
        <other:notUnderstoodExtendedSequence>
             <invoke/>
             <validate/>
             <assign>
                 <target name="crossesExtensionActivity"/>
             </assign>
        </other:notUnderstoodExtendedSequence>
    </extensionActivity>
</flow>


then the fact that someone won't understand the notUnderstoodExtendedSequence means that they're not going to know what to do with the assign embedded inside.  Since that assign contains the target of the link, they won't know what to do with the process.  Therefore to maintain portability, we're proposing that ALL processors must reject the process.  Note that we're not talking about standard elements on the extensionActivity itself, but those contained within embedded activities.

First - do you agree with that sentiment?
Second - if you do, then we can go ahead with new wording, possibly with an example.

I think the simplest wording, that doesn't include any rationale or examples, etc., would be along the lines of:

Any link that has an extensionActivity as a source or target is legal.  However, links MUST NOT cross an extensionActivity into a contained activity if the  namespace of the extensionActivity is not declared with mustUnderstand="yes."

Granted that still isn't simple...

Alex Yiu wrote:

Hi, Rania and others,

I would also suggest removing the implementer's note.

Few more points to suggest/make:
  • If we decide to make a normative change to ignore links within an extensionActivity that a WS-BPEL Processor does not understand. We should apply this ignore semantic consistently to all standard attributes and elements.
  • I am not sure the "if-then" logic about a link crosses the boundary of an
    <extensionActivity> is crispy clear. People may mis-read it in a way that "mustUnderstand" declaration can be set/reset by a WS-BPEL processor itself. It also implies a potential confusing error message "Cannot understand an extension declared with mustUnderstand='yes' ..." instead of "Dangling links ..."
  • The term "artifact"  usually refers to something with a bigger granularity. I would suggest to use "construct" instead. That is also more consistent with other parts of the spec.
--------------------------------------
In such a case (where the <extensionActivity> is treated as <empty>)
all enclosed constructs, including standard attributes and elements, in the <extensionActivity> MUST be ignored to a processor that does not understand the
extension. Ignoring standard elements would imply ignoring links in some cases.
If a link crosses the boundary of an <extensionActivity>, which a processor does not understand, dangling links are resulted and such a process definition is rejected.

--------------------------------------

Also, remove the sentence started with "In all cases however any standard-attributes or
standard-elements ..."



Regards,
Alex Yiu


Danny van der Rijn wrote:
I would remove the implementer's note.

Danny

Rania Khalaf wrote:

CURRENT TEXT ON EXTENSION ACTIVITY IN SECTION 10:

If the element contained within the extensionActivity element is not
recognized by the BPEL processor and is not subject to a
mustUnderstand="yes" requirement from an extension declaration then
the unknown activity MUST be treated as if it were an empty
activity. In all cases however any standard-attributes or
standard-elements used on the contained activity MUST be treated as
defined by this specification.

INSERT AS BEFORE TO LAST SENTENCE (between 'empty activty' and 'in all
cases'):

In such a case (where the <extensionActivity> is treated as <empty>)
all enclosed artifacts, including links, in the <extensionActivity>
are not visible to a processor that does not understand the
extension. To avoid dangling links in these situations, the following
restriction must be met. If a link crosses the boundary of an
<extensionActivity>, then the element contained within the
<extensionActivity> MUST be subject to mustUnderstand="yes".

Implementers note: This can be detected if a processor that does not
understand certain extensionActivities replaces them with <empty>
activities *before* doing static validation.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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