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] Groups - wsbpel_main-Sept-02-2004.xsd uploaded


Alex,

 

Thanks for the clarification.

 

[1] I am not sure how/why my copy of the attr properties got mangled – but I don’t see the prefix anymore

[2] I have read this section of the spec a dozen times now – and I come up with a different conclusion every time based on all the conditions.  I am leaning toward your interpretation – but as you state in item three….

[3] It may make more sense to explicitly state mixed = true – but I will let the group decide. 

 

I figured that there was a reason for these “do nothing” derivations – but still seems redundant to me….it’s still just an expression.

 

Yes – I ran it through XSV as well – and several others.  Really surprised me when Xerces flagged the ‘mixed’ error in previous version – but not latest.

 

Thanks again.

 

Ian

 

 

 

 

 

 

 

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, September 09, 2004 4:51 PM
To: ianh@tibco.com
Cc: pyendluri@webmethods.com; wsbpel@lists.oasis-open.org; Alex Yiu
Subject: Re: [wsbpel] Groups - wsbpel_main-Sept-02-2004.xsd uploaded

 


Hi, Ian,

Thanks for reviewing the XSD files.

[1]
I have doubled check with my local version of XSD and uploaded version:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/9095/wsbpel_main-Sept-02-2004.xsd
===============================

- <complexType name="tCorrelationSet">

-   <complexContent>

-       <extension base="bpws:tExtensibleElements">

-         <attribute name="properties" use="required">

-             <simpleType>

                 <list itemType="QName" />

            </simpleType>

        </attribute>

          <attribute name="name" type="NCName" use="required" />

      </extension>

  </complexContent>

</complexType>

===============================
I don't see the first problem you mentioned.  (??)
And, the QNAME comes from XSD NS. (Not "" empty NS).
 

[2] About mixed="true" situation in dervied type extension:

 I am afraid we may run into some XSD spec interpretation situation (or even a bug in XSD spec - particularly the "complexType" definition in the "Schema for Schemas" appendix )

Quoted from the schema spec:
"Schema Component Constraint: Derivation Valid (Extension)"
"1.4.3.2.2.1 Both {content type}s must be mixed or both must be element-only."

The way I read the sentence is the "mixed" attribute of the base type and derived type must be consistent. It does not require the "mixed" attribute must be stated explicitly in "complexContent" element.

If you look at Appendix A: "Schema for Schemas (normative)",
particular on the part of "complexContent" definition.
===============================

  <xs:element name="complexContent" id="complexContent">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-1/#element-complexContent"/>
    </xs:annotation>
    <xs:complexType>
      <xs:complexContent>
        <xs:extension base="xs:annotated">
          <xs:choice>
            <xs:element name="restriction" type="xs:complexRestrictionType"/>
            <xs:element name="extension" type="xs:extensionType"/>
          </xs:choice>
          <xs:attribute name="mixed" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
       Overrides any setting on complexType parent.</xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>

===============================

The "mixed" attribute of complexContent is optional. It will will inherit from the base type.
(But, there is a problem in "complexType" definition).

I did try to use XSV to validate the current schema.
http://www.w3.org/2001/03/webdata/xsv
It does not complain the XSD so far.

Anyway, I don't have problems to state mixed="true" explicitly to avoid interpretation issue of the XSD spec, if you truely prefer that. E.g.:
===========================
    <complexType name="tBoolean-expr" mixed="true" >
        <complexContent mixed="true" >
            <extension base="bpws:tExpression"/>
        </complexContent>
    </complexType>
===========================


[3] About using tExpression directly
There were different kinds of expressions defined in XSD, when those expression were still simple types. (Before I started working on BPEL XSD 6 moths ago)
======================
    <simpleType name="tBoolean-expr">
        <restriction base="string"/>
    </simpleType>
======================
 
I basically follow the same derivation pattern to switch those expression from simpleType to complexType.

My speculation of these "do-nothing" derivation is for ease of XSD code maintenance and clarity and documentation. It will be easier for people to verify whether the XPath expression from tBoolean-expr actually produce a boolean result.

Does it make sense to you?



Regards,
Alex Yiu




Ian D. Hunter wrote:

I believe that there are some minor errors in the
wsbpel_main-Sept-02-2004.xsd.
 
First - it seems as though the attribute "properties" type is incorrectly
prefixed
 
        <complexType name="tCorrelationSet">
               <complexContent>
                       <extension base="bpws:tExtensibleElements">
                               <attribute name="properties" use="required">
                                      <simpleType>
                                              <list
itemType="bpws:QName"/>
                                      </simpleType>
                               </attribute>
                               <attribute name="name" type="NCName"
use="required"/>
                       </extension>
               </complexContent>
        </complexType>
 
QName is not defined in the xmlns:bpws.
 
The next four errors are more subtle.
 
tCondition, tDuration-expr, tDeadline-expr and tBoolean-expr - all extend
tExpression - which is mixed="true"
 
According to the spec - the types must explicitly state that they are mixed
as well:
 
http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#cos-ct-extends
 
Section:  1.4.3.2.2.1
 
This is a particular confusing portion of the spec - so I should ask 'why
all these additional named types that just extend a type without adding
anything?"
 
Why not just use tExpression instead?  Example:
 
<complexType name = "tTargets">
  <complexContent>
    <extension base = "bpws:tExtensibleElements">
      <sequence>
         <element name = "joinCondition" type = "bpws:tExpression"/>
         <element name = "target" type = "bpws:tTarget" maxOccurs =
"unbounded"/>
      </sequence>
</extension>
</complexContent>
</complexType>
 
I am sure that there is a good reason - just seems redundant to me.
 
Thank you,
 
Ian Hunter
Senior Product Manager XML Technologies
TIBCO Software, Inc.
 
 
Error WSBPEL.xsd line 629, column 42: in type "tCondition" in namespace
"http://schemas.xmlsoap.org/ws/2004/03/business-process/":   type
"tCondition" in namespace
"http://schemas.xmlsoap.org/ws/2004/03/business-process/":
#cos-ct-extends.1.4.3.2.2.1: Extending complex types must preserve the
'mixed' state of the base type
Error WSBPEL.xsd line 657, column 42: in type "tDuration-expr" in namespace
"http://schemas.xmls
oap.org/ws/2004/03/business-process/":   type "tDuration-expr" in namespace
"http://schemas.xmlsoap.org/ws/2004/03/business-process/": #cos-ct-extends
.1.4.3.2.2.1: Extending complex types must preserve the 'mixed' state of the
base type
Error WSBPEL.xsd line 662, column 42: in type "tDeadline-expr" in namespace
"http://schemas.xmls
oap.org/ws/2004/03/business-process/":   type "tDeadline-expr" in namespace
"http://schemas.xmlsoap.org/ws/2004/03/business-process/": #cos-ct-extends
.1.4.3.2.2.1: Extending complex types must preserve the 'mixed' state of the
base type
Error WSBPEL.xsd line 652, column 42: in type "tBoolean-expr" in namespace
"http://schemas.xmlso
ap.org/ws/2004/03/business-process/":   type "tBoolean-expr" in namespace
"http://schemas.xmlsoap.org/ws/2004/03/business-process/": #cos-ct-extends.1
.4.3.2.2.1: Extending complex types must preserve the 'mixed' state of the
base type
Error WSBPEL.xsd line 274, column 49: in type "tCorrelationSet" in namespace
"http://schemas.xml
soap.org/ws/2004/03/business-process/":   in attribute "properties" in
namespace "":   unable to resolve reference to type "QName" in namespace
"http:
//schemas.xmlsoap.org/ws/2004/03/business-process/"
 
-----Original Message-----
From: pyendluri@webmethods.com [mailto:pyendluri@webmethods.com] 
Sent: Wednesday, September 08, 2004 7:36 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Groups - wsbpel_main-Sept-02-2004.xsd uploaded
 
The document wsbpel_main-Sept-02-2004.xsd has been submitted by Prasad
Yendluri (pyendluri@webmethods.com) to the OASIS Web Services Business
Process Execution Language TC document repository.
 
Document Description:
Sept 02, 2004 version of the WS-BPEL main schema. 
 
 
 
The message properties and partnerLinkType schemas have not changed since
the last revision and can still be found at [1] and [2] Respectively.
 
[1]
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8471/wsbpel
_msgprop-July-30-2004.xsd
 
[2]
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/8472/wsbpel
_plinkType-July-30-2004.xsd
 
Download Document:  
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/9095/wsbpel
_main-Sept-02-2004.xsd
 
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/document.php?document_id
=9095
 
 
PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.
 
 
 
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.
php.
 
 
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
 
  

 



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