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 - 111 - The text for my modification of Paco's Proposal


Hi Alex,

 

I realized that ambiguity, but felt it fell into the category of the engine has to deal with the true legality of the activity anyway.  I couldn’t find anything in schema that prohibited it, although I am not a schema expert.  Then I tested some documents and they worked with the parser I used.  As you probably figured what I was attempting to do with the ##any was allow container type extensions like:

 

<extensionActivity extensionName="the:scopeActivityExtension">
    <sequence>
      <invoke … />
      <assign … />
    </sequence>
    <the:finally>
      <assign … />
    </the:finally>
</extensionActivity>

 

Would this be rejected by an xml validator, because of the ambiguity?

 

- Chris

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, June 22, 2005 7:11 PM
To: chris.keller@active-endpoints.com
Cc: ygoland@bea.com; 'wsbpeltc'; Alex Yiu
Subject: Re: [wsbpel] Issue - 111 - The text for my modification of Paco's Proposal

 


Hi,  Chris,

Nope. :-) We could not.
Otherwise, we would run into the infamous undeterministic content model / ambiguous grammar tree problem again.

Because, tActivity's own xsd:any can "touch" tExtensionActivity's xsd:any in that case directly. (Because, <sources> and <targets> are optional)

I guess you guys understand more now on why some of us were so passionate on this issue, because we could have one simpler solution to kill all birds of ambiguous grammar tree problems. Unfortunately, the standard voting process guided us to a more complicated path of leaving this "ambiguous grammer forrest".

NOTE: I need to stress the past tense here: "were so passionate".


Regards,
Alex Yiu


Chris Keller wrote:

Hi Yaron,
 
Couldn't we define the tExtensionActivity with an <any> for elements after
the base?  Something like:
 
     <complexType name="tExtensionActivity">
         <complexContent>
             <extension base="bpws:tActivity">
                <sequence>
                   <any namespace="##any" processContents="lax" 
                        minOccurs="0" maxOccurs="unbounded"/>
                 </sequence>
                 <attribute name="extensionName" type="QName"/>
             </extension>
         </complexContent>
     </complexType>
 
So we can handle:
 
<extensionActivity extensionName="the:LoggingActivity">
    <targets>
       <target linkName="foo"/>
    </targets>
    <the:LoggingConfiguration>
       <the:LogName>foo.art#1</the:LogName>
       <the:LogLevel>3</the:LogLevel>
    </the:LoggingConfiguration>
</extensionActivity>
 
Also note the use of ##any that way if one wanted a container type activity
one could put a BPEL activity directly as a child element.  
 
The one catch on all this is the one you pointed out during the call today
and that is that one doesn't define a schema type for the:LoggingActivity.
So a decision on whether an extension activity is in legal form would be
left up to the engine/extension processor, not described in a schema.
Although with all the other static analysis that a BPEL engine has to do
this probably is not much of an issue.
 
- Chris
 
-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, June 22, 2005 5:57 PM
To: wsbpeltc
Subject: [wsbpel] Issue - 111 - The text for my modification of Paco's
Proposal
 
I think my original, unamended, proposal is best but if we are going to 
insist on putting the standard attributes and elements on the wrapper 
then I think the approach I outline below is the best one to take.
 
111 - Extension Activities (alternative proposal)
 
Proposal: Add an extensionActivity element to enable extension activities.
 
Introduce Section 11.9
 
New activities can be introduced for use in BPEL via the 
extensionActivity element.  The extensionActivity element has the same 
standard attributes and elements as any other BPEL activity. But in 
addition the extensionActivity has the extensionName attribute that is 
used to identify the semantics associated with the extension activity. 
If an extensionName is not recognized by a BPEL processor and if the 
namespace from which the extensionName is taken is not subject to a 
mustUnderstand="true" requirement from an extension declaration then the 
unrecognized extension activity MUST be treated as if it were an empty 
activity.
 
<extensionActivity extensionName="QName" standard-attributes>
       standard-elements
</extensionActivity>
 
Due to the limitations of the XML Schema processing model it is not 
possible to put new content from non-BPEL namespaces after the 
standard-elements.
 
For example, the following hypothetical extension activity is schema 
invalid:
 
<extensionActivity extensionName="the:LoggingActivity">
    <targets>
       <target linkName="foo"/>
    </targets>
    <the:LoggingConfiguration>
       <the:LogName>foo.art#1</the:LogName>
       <the:LogLevel>3</the:LogLevel>
    </the:LoggingConfiguration>
</extensionActivity>
 
Instead the activity would have to be specified as follows:
 
<extensionActivity extensionName="the:LoggingActivity">
    <the:LoggingConfiguration>
       <the:LogName>foo.art#1</the:LogName>
       <the:LogLevel>3</the:LogLevel>
    </the:LoggingConfiguration>
    <targets>
       <target linkName="foo"/>
    </targets>
</extensionActivity>
 
Schema:
 
Add to activity group:
     <element name="extensionActivity" type="bpws:tExtensionActivity"/>
 
Add the following definition:
     <complexType name="tExtensionActivity">
         <complexContent>
             <extension base="bpws:tActivity">
                 <attribute name="extensionName" type="QName"/>
             </extension>
         </complexContent>
     </complexType>
 
 
---------------------------------------------------------------------
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]