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

Hi,

Yes, Mark's example should be allowed.
Yes, agree with Danny that adding two examples that we have just created would benefits users a lot.

And, few minutes ago, I sent out some suggested text, which treats link as a part of standard-elements and dangling link case as one of examples of static analysis.

IMHO, having a general statement on what to ignore and what not to ignore is a better option than singling out links for special treatment.

Thanks!

Regards,
Alex Yiu


Danny van der Rijn wrote:
I'm thinking that

<extensionActivity>
        <other:notUnderstoodExtendedSequence>

is one activity, while you're thinking they're two.

All links will cross the <extensionActivity> element boundary to a contained element. However, your example doesn't cross the <extensionActivity> activity boundary, while mine does.  At least if one interprets the above 2 elements as one activity.

It seems to me that all the careful wording in the world, though, even if it's 1000 words' worth, won't equal the examples we've just created.

Mark Ford wrote:
Should this be allowed:
 
<flow>
    <link name="crossesExtensionActivity"/>
   
    <receive>
       <source name="crossesExtensionActivity"/>
    </receive>

    <extensionActivity>
        <other:notUnderstoodExtendedSequence>
             <target name="crossesExtensionActivity"/>
             <invoke/>
             <validate/>
             <assign/>
        </other:notUnderstoodExtendedSequence>
    </extensionActivity>
</flow>
 
The above example collapses easily enough into an empty without any errors.
 
The <extensionActivity> element doesn't have the standard attributes and standard elements so we should be careful about boundary crossing terminology since all links will cross the <extensionActivity> boundary into a contained element.
 
How does this sound:
 
Links MUST NOT cross an extensionActivity into an activity that is not the immediate child of the <extensionActivity> unless the namespace for the extension has been declared with a mustUnderstand="yes".
 
 

From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Friday, March 31, 2006 4:55 PM
To: Alex Yiu
Cc: Rania Khalaf; wsbpeltc
Subject: Re: [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

--------------------------------------------------------------------- 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]