[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 294 - subissue - 294.2 - Proposal for Discussion- Clarification of normative status of XML Schemas and decisions on preferreddesign patterns
Hi Thomas, Thank you for agreeing that "one might be discussed and approved much more faster than the other", if we split the issue discussion. I don't disagree that we may want to discuss the GED and other schema design pattern. So that it would be a conscious choice of the TC, instead of an editorial choice. Not to repeat myself, here is a previous email from me on this thread: http://lists.oasis-open.org/archives/wsbpel/200606/msg00041.html To respond to your previous two emails, I will try to keep the email short. :-) ... But, I still want to make sure some facts are presented correctly, especially about XSD technical details and fundamentals of compiler design (separation of syntax grammar and semantics analysis). (1) Normative status I would prefer a normative schema also. But, if we cannot reach a sensible consensus among us, I would not oppose having the schema as non-normative (i.e. illustrative). (1.1) GED does NOT imply a root element Yes, it is very clear to all of that there are only 4 elements are root-elements defined in BPEL spec for BPEL NS. However, you are making an assumption that GED implies root elements in XSD. That assumption is not true. See the Normative XML Schema for Schema and WSDL 2.0 Schema. They are using GED to denote a NON-ROOT-element of global significance. If a normative Schema for Schema in XML Schema spec is NOT authoritative enough to state that GED not=> Root Element in XML schema usage, I don't know what will change your mind. :-) (2) Allowing multiple schema documents for same target namespace will make us unable to enforce schema comprehensively As I mentioned before, if we ever allow multiple schema documents to define elements of the same targetnamespace without a top-level including XSD will give us a lot of trouble to enforce the schema. (2.1) One schema location per target namespace in an XML Schema Validator Instance Have multiple top level XSD of the same target namespace is analogous to having multiple jar files in java for the same java package. But, there is a big difference: you can have a classpath of multiple jar locations. But, in XML Schema you cannot have multiple schema locations. To join multiple xml schema files, you must have a top-level schema to include a bunch of schema. (2.1.1) Reference to XML Schema Specification where states one location per NS See the definition of xsi:noNamespaceSchemaLocation : ------------------------------------- Attribute Declaration for the 'noNamespaceSchemaLocation' attribute
For no-namespace schema location, there is only one single URI, not multiple URIs. For namespace schema location, similar constraint is applied to ensure that: (quoted from spec) a schema processor can "resolve the namespace name to locate such a resource" (See under "Schema Representation Constraint: Schema Document Location Strategy", bullet #5) (2.1.2) Which schema to apply? If we allow multiple schema documents as the top level schema, which one we should pick? Assuming we have 3 XSD (for service-ref, business-process and wsdl) to describe BPEL NS and we obtain an element embedded in a XML payload via a network. -------------------------- <bpel:someNonExistentElementXYZName/> -------------------------- Which XSD we should apply? Note: we do not have a file extension to hint which category information we are looking? Do we need to run XSD validator 3 times? And, pick the one which is successful? Or, we should peek into the element name first then to decide which XML Schema to apply to. (2.1.3) If multiple schema, how can we validate both <process> and <service-ref> elements? Given in a XML schema validator instance, one can only have schema location per namespace. One cannot run a single validator to validate both <process> and <service-ref>. E.g.: ----------------------------------- <process> ... <assign> <copy> <from> <service-ref someIllegalAttribute="abc" > ... </service-ref> </from> <to ... /> </copy> ... </assign> ----------------------------------- I have done some experiements with XML schema validator already (including Xerces). If we don't have a top-level schema that cover both <process> and <service-ref>. We cannot do validation comprehensively. If you want, I can send you a zip of my testing XSD and XML files to prove/illustrate further. (2.2) **If** we add 2 more NS, then we can do de-referenceable NS that way. Do we want to have that many NSes just for spilting schema just for sake of unnecessarily forcing GED as Root Element (2.3) If I follow your suggestion, we can avoid duplication type definition but NOT definition declaration. Two LED of the same QName (say <bpel:scope>) are NOT the same element declaration. One can have nillable="true", the other can have nillable="false". (2.4) No other specifications split the schema of the same target namespace Splitting XML schema of the same target namespace was a mistake in BPEL 1.1 spec. We should correct that mistake. I have NOT seen other specification does that. If you can find one in other standards, please show me. Thomas wrote: Everyone is doing this (too with other artifacts, i.e. WSDL) and XML Schema explicitly allows that. You are missing my points. Maybe, it is lost in translation situation (English-to-German). Yes, you can multiple schema document of the same target namespace. However, when you have multiple XSD of the same target namespace, you need to include together as one top-level XSD before being used in XML Schema processor. [See points in (2.1.1)]. You can have an XML documentation with a schemaLocation similar to following: ----------------------- <bpel:process xsi:schemaLocation="bpel-ns-uri bpel-process.xsd bpel-ns-uri bpel-service-ref.xsd" ... > </bpel:process> ----------------------- It should be like the following instead: ----------------------- <bpel:process xsi:schemaLocation="bpel-ns-uri the-bpel-merged.xsd" ... > </bpel:process> ----------------------- (3) GED vs LED (3.1) GED implied by Spec Text I think I said GED is implied by the spec text. I am not sure why you read the opposite. I guess lost in translation again or some not-so-visible typo. :-) (3.2) Identified by QName and GAD (3.2.1) When I said elements are referenced by QName, I don't mean literally. When we use "invoke" or "<invoke>" to refer to the invoke element, we just opt out the prefix/namespace for brevity and convenience. If we change it to "bpel:invoke", the spec reads 100% the same. If the syntax definition of "invoke" was not unique under its QName, we need to specify "invoke" under which parent element. (3.2.2) About GAD (Global Attribute Declaration) XMLNS Specification Clarification: "<invoke>" can come with a default NS depending on the context (in some cases the default namespace is empty). On the other hand, attribute "attrX" always does NOT come any namespace **ever**. Default namespace does NOT apply to attribute. A namespace attribute must always have a prefix. We are not using GAD because:
(3.2.3) LED and Separation of Syntax and Semantics Analysis About your LED for <scope> argument, you are confusing yourself and other people that mixing syntax and semantics together. The syntax of <scope> is 100% the same, no matter whether it is used inside <onEvent> and <forEach> or ther activity container. (3.4) I agree with you about the intention of a schema. Again, you are making an assumption that GED=Root Element. That assumption is already shown not true in the schema design in WSDL 2.0 and XML Schema for Schema. (3.5) Fragments and etc (3.5.1) Fragments I agree with you that about one third of the core question on GED-vs-LED is whether we want to support syntax validation of BPEL Fragment. Again, I want to make Abstract Process and Execution Completion into a reality. e.g.: some psuedo XML info for Execution Completion ------------------------- <prefixX:executionCompletion insertionPoint="...."> <bpel:variable name="myVar" type="foo:bar" /> </prefixX:executionCompletion> ------------------------- GED allows further innovation and standardization on Execution Completion, while LED does not. I think the standard should still allow people to make it happen. Again, I am talking about syntax validation of BPEL fragment independent from semantic analysis. XML Schema is always about syntax analysis, NOT semantic analysis. Your question of "How are the BPEL-internal references of the link, variable and the partnerLink resolved?" Unfortunately, you are bluring/mixing syntax and semantic analysis again. If one get into the semantic analysis domain, the semantics of variable declaration cannot be achieved without knowing details of imported WSDL and XSD. (e.g. whether the messageType is defined in the WSDL). (3.5.2) Having most of elements as GED does NOT require any spec text changes at all. XML-Schema-Validated GED of <invoke> does NOT qualify a BPEL process. Because, the spec already explicit say that the syntax of a BPEL process is <process>. Similar to the case Schema Design of XML Schema 1.0 and WSDL 2.0. Thanks! Regards, Alex Yiu Thomas Schulze wrote: Hi Alex, my example in (3.5) is a little bit outdated ;-) Please ignore it. But lets replace it with the following: <bpel:assign> <bpel:targets> <bpel:target linkName="MyLink"/> </bpel:targets> <bpel:copy> <bpel:from> $MyVariable/tns:epr </bpel:from> <bpel:to partnerLink="MyPartnerLink"/> </bpel:copy> </bpel:assign> Equal questions rise up - How are the BPEL-internal references of the link, variable and the partnerLink resolved? There are no definitions for it. Are they invalid? - How are other normative statements satisfied that for example say something about type-compatibility? The type of the variable is not known. - What is the expression language (there's only a default on bpel:process)? - What is the value of suppressJoinFailure (there's only a default on bpel:process, too)? Adding an <extensibleAssign> into this example or another kind of extension element/attribute rises an additional question: - Since extensions can be declared only on process - the added extension, is it mustUnderstand="yes" or mustUnderstand="no"? The default would be "no" here. Therefore it would not be possible to use mustUnderstand="yes" extensions in BPEL fragments? That would be strange... Bottom line is that supporting BPEL fragments is currently totally unspecified and would require major changes in the spec. Therefore, IMO LEDs MUST be used in the schema. Best regards/Mit freundlichen Grüßen, Thomas Schulze ----- Forwarded by Thomas Schulze/Germany/IBM on 10.06.2006 09:07 ----- Thomas Schulze/Germany/I BM To Alex Yiu <alex.yiu@oracle.com> 09.06.2006 23:59 cc Alex Yiu <alex.yiu@oracle.com>, Dieter Koenig1/Germany/IBM@IBMDE, Diane Jordan <drj@us.ibm.com>, Peter Furniss <peter.furniss@erebor.co.uk>, wsbpel@lists.oasis-open.org Subject Re: [wsbpel] Issue - 294 - subissue - 294.2 - Proposal for Discussion - Clarification of normative status of XML Schemas and decisions on preferred design patterns(Document link: Thomas Schulze) Hi Alex, I have no strong feelings splitting up the issue into two. I agree that the one might be discussed and approved much more faster than the other. But I really think we need to open both of them. I think there is no other issue where the merging of the schemas and the introduction of GEDs have been discussed and formally approved. In case I've overseen it, can you please point me to this issue? If there is no issue with which this changes have been formally approved, I think we either need to discuss and formally approve a solution with this issue (or a sub-issue) or the merging of the schemas and the introduction of GEDs must be undone. That was my reasoning regarding the formal change process, now my technical reasoning regarding the proposed solution. (1) Normative status I agree with you that the schema must be normative, else there is no issue. If the decision is that the schemas are not normative, IMO it is pretty clear from the spec text that <process> is the only root element of a valid BPEL and nothing else is allowed. And it is pretty clear from the spec that <property> and <propertyAlias> are extensions to WSDL and therefore need to be GEDs, same for <service-ref>. (2) One or multiple schemas I don't agree with you on that point. (2.1) IMO splitting up the schema is more user-friendly, because it makes clear that all three schemas are for three different things. The main schema is the syntax description for the process definition itself, the property schema is for BPEL's WSDL extensions (as well as the partnerLinkType schema) and the service-ref schema is for use as a data type inside a process. This means the service-ref schema is intended to be a part of process definitions. Especially for this case it will be much more user-friendly if there's a separate schema containing only the service-ref stuff. Maybe we should think about introducing a separate namespace for <property> and <propertyAlias> (compare with partnerLinkTypes) and a separate namespace for <service-ref> to make the difference more clearer, not by only separating the schemas. But it might be to late for such a change. (2.2) When introducing new namespaces, the tns of these two schemas can be used as location for reference, too (your second point). (2.3) Avoiding duplication is done by including/importing the main schema into the other schemas. So there's really no duplication needed. (2.4) It's new to me that splitting up the same tns is no good practice. Everyone is doing this (too with other artifacts, i.e. WSDL) and XML Schema explicitly allows that. As described above the different element definitions are for different purposes and that should be documented by splitting up the schema. (2.5) Another important point here, the decision on that topic highly depends on the GED/LED discussion. If GED is used there is no additional argument for splitting up the schemas. But if we decide for LEDs it's obvious that the schemas need to be splitted up. Only then we really have only one element in the main schema. (3) GED vs. LED I don't agree with you on that point, too. (3.1) As you've said above the dotted list, GED is not implied by the spec ;-) So why do we need it? (3.2) Elements are NOT referenced by QName in the spec i.e. the string <bpel:invoke> is not contained in the spec. We always use 'invoke' or '<invoke>' in HTML Typewriter font. Too, we often refer attributes the same way. Following your argumentation we have to introduce Global Attribute Declarations (GAD), too. But this would make some existing BPELs invalid because the globally defined attributes then need to be prefixed with i.e. bpel: if the default ns is not set to BPEL. Furthermore, the spec does not require that a QName, i.e. <bpel:invoke>, is unique under it's tns. Furthermore the usage of LEDs underlines that for example <bpel:scope> used in <onEvent> is different than used as here: <bpel:process ...> ... <bpel:flow ...> ... <scope ...>...</scope> ... </flow> </process> In <onEvent> and <forEach> the spec puts additional requirements on the child scope, i.e. the variable syntactically 'defined' on <onEvent> is implicitly defined on the contained scope. This means the usage of the QName <bpel:scope> has slightly different semantics depending on where it is used and this can ONLY be expressed by using LEDs. (3.4) Intention of a schema. What's the intention of a schema? IMO it's (a) for documenting for other people in a standardized format the syntax of a data structure and (b) for schema validation. For both purposes LED is the only choice. The <process> MUST be the root element of a compliant WS-BPEL process. (3.5) Other specifications and fragments. I have not yet heard any good reason why other specifications have decided to use GEDs. All I have heard from other people working on other specifications is "It's up to you." I think the real question is: Does WS-BPEL allow a kind of stand-alone BPEL fragments as you have given an example for? I would say, no currently not (and that's the difference to other specifications). Looking at your very simple example, already rises the following question: How is the referenced type foo:bar imported? The spec currently says: "A WS-BPEL process definition MUST import all XML Schema and WSDL definitions it uses. This includes all XML Schema type and element definitions...". Is that true for this fragment? I don't know, it's undefined. Some may say yes and use bpel:import in the surrounding document to import that type, some may say no and use an own import mechanism. Looking at the following fragment example other big questions are not answered: <bpel:assign> <bpel:targets> <bpel:target linkName="MyLink"/> </bpel:targets> <bpel:copy> <bpel:from variable="MyVariable"> <bpel:query>tns:id</bpel:query> </bpel:from> <bpel:to partnerLink="MyPartnerLink"/> </bpel:copy> </bpel:assign> - How are the BPEL-internal references of the link, variable and the partnerLink resolved? There are no definitions for it. Are they invalid? - How are other normative statements satisfied that for example say something about type-compatibility? The type of the variable is not known. - What is the queryExpression (there's only a default on bpel:process)? - What is the value of suppressJoinFailure (there's only a default on bpel:process, too)? I think using GEDs in the schema and allowing fragments by that, introduces a lot of new questions which are not answered in the spec until now. That's an additional reason why we need to open this (sub-) issue and discuss about it. I prefer LEDs. Answering all these questions would require massive changes in the spec because the whole spec is written in the assumption that there are no fragments allowed. Dieter mentioned in a previous mail to check the copyrights if an extension can introduce GEDs when it needs them. Maybe we should discuss this option, too. Best regards/Mit freundlichen Grüßen, Thomas Schulze Alex Yiu <alex.yiu@oracle. com> To Alex Yiu <alex.yiu@oracle.com> 05.06.2006 03:35 cc wsbpel@lists.oasis-open.org, Dieter Koenig1/Germany/IBM@IBMDE, Peter Furniss <peter.furniss@erebor.co.uk>, Diane Jordan <drj@us.ibm.com> Subject Re: [wsbpel] Issue - 294 - subissue - 294.2 - Proposal for Discussion - Clarification of normative status of XML Schemas and decisions on preferred design patterns Hi all, Given this list of discussion items: ----------------------------------------------- Subject: Issue - 294.2 - Clarification of normative status of XML Schemas and decisions on preferred design patterns Description: Normative Status: Whether the XML Schema provided this specification is normative was discussed in a conf call few weeks ago. However, there was no formal conclusion reached during the conf call. A formal clarification/decision should be reached before discussing other topics regarding to schema and grammar enforcement by the specification. Another question include: do we allow WS-BPEL implementation to implement other xml grammar language to enforce the syntax of this specification? XML Schema Design Patterns: One or multiple schema document: For XML syntax of one particularly target namespace, should we have one XML schema to cover its definition? Or, we should have a set of disjoint XML schemas to cover one namespace? GED-vs-LED: In XML Schema, an element can be in forms of either Local Element Declaration (LED) or Global Element Declaration (GED). Which pattern are the preferred one? There are different pros and cons in this decision. In BPEL 1.1 main XML schema, there are a number of elements which are GED: "process", "from" and "to" ----------------------------------------------- Proposal Draft (so far, subject to further discussion): Normative status of XML Schema: Based on what I heard so far, people seem to prefer XML schema being normative. I would presume that is the direction that we want. However, I am personally open to make the XML schema non-normative (i.e. an illustrative example grammar). Here is the proposed text to add as the preamable of XML Schema Appendix: ----------------------------------------------- XML Schema listed in this appendix are considered normative parts of the specification and used to provide further grammar restrictions on WS-BPEL syntax desribed by the main part of this specification. If XML Schema has contradictions with the main part of this specification, instead of restriction, the main part of the specification are considered to be the source of truth. This specification does NOT mandate implementation of WS-BPEL processors to use XML Schema as the only mechanism to perform grammatical checking of WS-BPEL constructs. Other mechanisms are allowed to be used as long as the result does not contradict the main part of the specification. ----------------------------------------------- Past Discussion: http://www.oasis-open.org/archives/wsbpel/200605/msg00121.html http://www.oasis-open.org/archives/wsbpel/200605/msg00138.html http://www.oasis-open.org/archives/wsbpel/200605/msg00146.html One or multiple schema document per target namespace: I suggest to have one schema document per target namespace. Because: It will be more user-friendly (Dieter's point) Make it feasible to make the target namespace is a de-referenceable location for people to fetch schema (See opened issue 289) To avoid duplication of XML Schema(See Issue 192 to make <property> and <propertyAlias> extensible) and to avoid conflicting as well (Note: different schemaLocation is like different classloader). There are no other XML / WS-* (AFAIK) specification would spilt the schema definition of one target namespace into multiple pieces. (Spiltting schemas up is not a good practice.) GED-vs-LED: This may be the most complicated item for discussion for this issue. I propose that we should use GED whenever possible in our schema design. I think that GED is neither useless nor implied by the spec text. Let me summarize reasons mentioned in some of past discussion here: Spec Text Implies GED: In our spec text, we usually refer to an activity or a construct just with its QName (e.g. <bpel:invoke>, <bpel:assign>, <bpel:eventHandlers>). That essentially means that QName is globally unique under that targetNamespace. There are NO more than one definition of <bpel:eventHandlers>. XML Schema should reflect that intention as much as possible by using GED. GED != Root Element and Majority of XML and WS* Spec are using GED: In XML Schema specification, Schema for Schema are using GED as much as possible, even though <xsd:schema> is the only valid Root Element. Similarly situation applied to WSDL 2.0 and a bunch of other WS-* specification. They use GED extensively on non-Root Element. It really means GED does NOT imply that element is a root element. That is **the** trend of all well-know specifications. In fact, WSDL 1.1 is using a lot of LED, while WSDL 2.0 transits to use GED. BPEL 1.1 => BPEL 2.0 should follow a similar transition. If we use LED in BPEL 2.0, that would essentially saying to WSDL 2.0 and XML Schema authors that they made a wrong decision. [ Another example XML Schema for XML Syntax for XQuery (XQueryX) ] BPEL Fragment Support for Execution Completion: When people uses BPEL fragments to contain the Execution Completion information of Abstract Process, it would be very beneficial that Execution Completion XML information can refer to the Elements of BPEL syntax and reuse the XML schema syntax validation. e.g.: some psuedo XML info for Execution Completion ------------------------- <vendorX:executionCompletion insertionPoint="...."> <bpel:variable name="myVar" type="foo:bar" /> </vendorX:executionCompletion> ------------------------- If <bpel:variable> is a local element only in our schema, then vendorX will may need to define its own with the targetNamespace pointing to bpel namespace, in order to do syntax validation. That is just a bad practice that a namespace owned by an OASIS spec and but a vendor can define and declare things that namespace. It is similar to the situation that a vendorX define a new class in the java package "javax.some-java-standard" owned by the standard. To make Execution Completion as an implementation reality, we need BPEL fragment supports in XML Schema in forms of GED. The only reason against using more than one GED in a schema design is: before / after the schema validation, a WS-BPEL processor needs to verify whether the root element is <bpel:process>. That is a super easy step to do. Given the schema for schema design and WSDL 2.0 as our predecessor example, it should not be a problem, e.g.., an XSD processor would not accept a schema started with <xsd:documentation> as their root element. Thanks! Regards, Alex Yiu Alex Yiu wrote: Hi, Dieter, I am a bit confused. I thought we would try to cover Action Item #74 by this issue as well? http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434 Also, I suggested to declare formally how normative XML Schema Artifacts are. Before we go into the GED-vs-LED discussion. If the XML Schema is informal, there is no point to have a GED-vs-LED discussion. The first 3 bullets mentioned in the issue description is related to the namespace usages, while the fourth is about schema design. They are orthogonal to each other. One decision does not affect the other. We should NOT mix these group issues together. Implementation may use other non-XML-schema to enforce the grammar specified by the spec text or XML schema. Also, it seems to me that there would be multiple XML Schema document for the same Exec-BPEL in the submitter's proposal. I thought I was able to at least to convince Dieter that one schema document for one target namespace is a good practice: See: http://www.oasis-open.org/archives/wsbpel/200605/msg00146.html Now I am really confused. Anyhow, I formally suggest to add some of the above concerns to this issue description and spilt this issue into two sub-issues: one for namespace usage; one for XML Schema status and design pattern. [Assume the namespace related issue is numbered as "294.1".] ----------------------------------------------- Subject: Issue - 294.1 - Clarification namespace usage in Abstract and Executable Process Description: According to the resolution of issue 24, there will be two WS-BPEL 2.0 XML schema artifacts, each with its own target namespace, one for Executable Processes and one for Abstract Processes. There are several problems associated with this approach: 1. The XML schema types and elements for Properties and Property Aliases appear currently in the Executable Process namespace. It is *unclear* whether they should also be in the Abstract Process namespace as well. If they are, then it is *unclear* which one to use in the WSDL. 2. The XML schema types and elements for Service References would similarly appear in both namespaces - it is *unacceptable* that the namespace changes when switching between Abstract and Executable - if this schema type would appear on a WSDL operation then this switch would cause a change of the interface. 3. For XPath extension functions defined by WS-BPEL, we again have the same situation: is is unclear whether both namespaces would be used to qualify them - again, it is *unacceptable* that the namespace changes when switching between Abstract and Executable. Also, we do not have text to describe how to treat XPath function of other namespaces. See action item #74 http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434 ----------------------------------------------- [Note: (1),(2),(3) are exact copies of Dieter's original issue description. Green text are added for Action #74. In general, for (1) to (3), I agree with Dieter's general direction. Use "bpel" ns, instead of "abstract" ns all the time in these 3 context. And, I would propose adding text from Action #74 as well.] ----------------------------------------------- Subject: Issue - 294.2 - Clarification of normative status of XML Schemas and decisions on preferred design patterns Description: Normative Status: Whether the XML Schema provided this specification is normative was discussed in a conf call few weeks ago. However, there was no formal conclusion reached during the conf call. A formal clarification/decision should be reached before discussing other topics regarding to schema and grammar enforcement by the specification. Another question include: do we allow WS-BPEL implementation to implement other xml grammar language to enforce the syntax of this specification? XML Schema Design Patterns: One or multiple schema document: For XML syntax of one particularly target namespace, should we have one XML schema to cover its definition? Or, we should have a set of disjoint XML schemas to cover one namespace? GED-vs-LED: In XML Schema, an element can be in forms of either Local Element Declaration (LED) or Global Element Declaration (GED). Which pattern are the preferred one? There are different pros and cons in this decision. In BPEL 1.1 main XML schema, there are a number of elements which are GED: "process", "from" and "to" ----------------------------------------------- I will send a seperate email to submit a proposal for the second subissue. Thanks! Regards, Alex Yiu ws-bpel issues list editor wrote: This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received". The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL. Issue - 294 - Factoring of XML Schema Artifacts Status: received Date added: 4 Jun 2006 Date submitted: 02 June 2006 Submitter: Dieter Koenig Document: WS-BPEL 2.0 XML Schema Description: According to the resolution of issue 24, there will be two WS-BPEL 2.0 XML schema artifacts, each with its own target namespace, one for Executable Processes and one for Abstract Processes. There are several problems associated with this approach: 1. The XML schema types and elements for Properties and Property Aliases appear currently in the Executable Process namespace. It is *unclear* whether they should also be in the Abstract Process namespace as well. If they are, then it is *unclear* which one to use in the WSDL. 2. The XML schema types and elements for Service References would similarly appear in both namespaces - it is *unacceptable* that the namespace changes when switching between Abstract and Executable - if this schema type would appear on a WSDL operation then this switch would cause a change of the interface. 3. For XPath extension functions defined by WS-BPEL, we again have the same situation: is is unclear whether both namespaces would be used to qualify them - again, it is *unacceptable* that the namespace changes when switching between Abstract and Executable. 4. The XML schema contains many global element definitions instead of just <process> - it is therefore allowed to create valid documents that only contain a <property> element (or a <copy> element, etc.), which is useless and not mandated by the WS-BPEL 2.0 specification. Submitter's proposal: [Just one option - subject to discussion] Refactor the WS-BPEL 2.0 XML schema artifacts into the following: a. One WS-BPEL 2.0 XML schema for validation of Executable Processes - the only allowed root element is <executable:process> b. One WS-BPEL 2.0 XML schema for validation of Abstract Processes - the only allowed root element is <abstract:process> c. One WS-BPEL 2.0 WSDL extension XML schema for validation of Properties and Property Aliases - same target namespace as (a) - the only allowed root elements are <bpel:property> and <bpel:propertyAlias> d. One WS-BPEL 2.0 XML schema for Service Reference variable declaration in Executable or Abstract Processes - same target namespace as (a) - the only allowed root element is <bpel:service-ref> Notes: The target namespace values for (a) and (b) are valid URLs that point to the location of the two artifacts, respectively. The location of (c) and (d) is provided in a <xsd:documentation> element contained in (a) and (b). The XML schema artifact (c) has an <xsd:include> for the schema (a) in order to be able to reuse the WS-BPEL extensibility mechanism. Changes: 4 Jun 2006 - new issue To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 294 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 294 - Proposed resolution", without any Re: or similar. To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement). --------------------------------------------------------------------- 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]