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