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 - 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
Property Value
{name} noNamespaceSchemaLocation
{target namespace} http://www.w3.org/2001/XMLSchema-instance
{type definition} The built-in anyURI simple type definition
-------------------------------------
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:
  • We don't have global signficance in our attribute. In our spec text, we would usually qualify the attribute with an element not with a namespace.
    e.g. " keepSrcElementName attribute of the <copy>"
    If we had really an attribute of global signficance, then yes we should use GAD (e.g.  wsp:Optional="xs:boolean" and wsu:Id="xs:ID"). Note this GAD is usually used when we need cross-namepace usage identification. But we don't have such an attribute. [On the contrary, please see (3.5) on the GED front, which I do intend to enable an effective execution completion in future standard for Abstract Process.]
  • If we had such a GAD, then the syntax notation in our spec would be "bpel:someGAD". However, the spec text does not use prefix. So, it will be incorrect for anyone to assume that is a GAD.

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