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'sProposal



Hi, Chris,

[A]
Regarding to XSD spec, here is the link to point to the requirement of making XSD unambiguous:
http://www.w3.org/TR/xmlschema-1/#cos-nonambig

[B]
In terms of XML parser implementation, I am too aware of some of them (e.g. Xerces) do not enforce this unambiguous requirement. I am not sure why they deviates from the spec. For xerces, it basically uses "first-come-first-match" algorithm to ignore the ambiguous nature of a given XSD. That in turn creates some interesting and surprising XML validation results when the XSD is ambiguous and XML instance document is ambiguous.

One can use the XSV validator hosted by W3C.
http://www.w3.org/2001/03/webdata/xsv
(it will report the ambiguous problem in the schema when "Check as complete schema" checkbox is checked)


[C]
One thing that I agree with you is: Yaron's most recent alternative proposal (not his original proposal) may not be enough for some of usecases / features.

And, I sent out a list of 4 features for evaluation criteria for extension activity syntax. Here I copy a part of my previous email again for convenience.

Extension Activity Syntax : evaluation / testing criteria
http://lists.oasis-open.org/archives/wsbpel/200506/msg00164.html
==================================
-------------------------------------
<bpel:forEach
              name="myForEach" suppressJoinFailure="no"
              indexVariable="int" parallel="yes"
              bpeldesigner:nodeId="123" >
       <superLink:source multicastLink="mySuperLink3" />

       <bpel:targets>
              <bpel:target linkName="myLink2" />
       </bpel:targets>
       <bpel:iterator>
              <bpel:startCounterValue> 1 </bpel:startCounterValue>
              <bpel:finalCounterValue> 4 </bpel:finalCounterValue>
       </bpel:iterator>
       <bpel:scope name="innerScope">
              ...
       <bpel:scope>
</bpel:forEach>
-------------------------------------

(1) Activity Specific Attributes and Sub-Elements (in BLUE): e.g.: "indexVariable", "parallel" and <iterator>.
(2) Extension attributes and elements (in BROWN): e.g.: "bpeldesigner:nodeId" and <superLink:source>
(3) Extension Activity as an activity container (in GREEN): e.g.: <forEach> contains <scope>
(4) Standard Attributes and Elements (in PURPLE): e.g. "name", "suppressJoinFailure", <bpel:targets>
==================================

Yaron's alternative proposal in the last email did not say clearly where activity specific attributes in (1) (e.g. "indexVariable" and "parallel") will end up. Similarly, it does not say it clearly how the extension activity contains a standard activity [as described in (3)]


[D]
Nevertheless, based on Yaron's alternative proposal and Chris's input, I may have come up with an XSD design that can address all four features above.

Here is the XSD:
===========================
    <complexType name="tExtensionActivity">
        <complexContent>
            <extension base="bpws:tActivity">
                <sequence>
                    <element name="extensionBody" minOccurs="0">
                        <complexType>
                            <sequence>
                                <any minOccurs="1" maxOccurs="unbounded"
                                         processContents="lax" namespace="##any" />
                            </sequence>
                        </complexType>
                    </element>
                </sequence>
                <attribute name="extensionName" type="QName" />
                <anyAttribute namespace="##any" processContents="lax" />
            </extension>
        </complexContent>
    </complexType>
===========================

  • <bpel:extensionBody> resolves the ambiguity issue.
  • xsd:any with  ns="##any" addresses feature (3)
  • anyAttribute with ns="##any" should adress feature (1)
    [** But,  I need to double check with my XSD dictionary :-) **]
**If** my interpretation of XSD is accurate, the above forEach example can be modeled as an extensionActivity as follow:

-------------------------------------
<bpel:extensionActivity extensionName="foo:forEach"
              name="myForEach" suppressJoinFailure="no"
              indexVariable="int" parallel="yes"
              bpeldesigner:nodeId="123" >
       <superLink:source multicastLink="mySuperLink3" />

       <bpel:targets>
              <bpel:target linkName="myLink2" />
       </bpel:targets>
       <bpel:extensionBody>
         <foo:iterator>
              <foo:startCounterValue> 1 </foo:startCounterValue>
              <foo:finalCounterValue> 4 </foo:finalCounterValue>
         </foo:iterator>
         <bpel:scope name="innerScope">
              ...
         <bpel:scope>
       </bpel:extensionBody>

</bpel:forEach>

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

I have highlighted all the syntax deltas between a standard "forEach" activity and an extension "forEach" activity in bold-and-italic.


Thanks!




Regards,
Alex Yiu




Chris Keller wrote:

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]