DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
| OASIS JIRA | Description | Tuscany TODO | Tuscany JIRA | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| for implentations.*'s fix attributes that should show qnames as values |
|
| |||||||||
Conformance | ||||||||||||
| Is binding.sca always present? | If a component service is configured with binding.ws, can be accessed by a component reference in the same composite with binding.sca? Reference side is different now. When no bindings it dervies them from service |
|
| ||||||||
| Is interface.java specification normative in SCA-Assembly spec? | No action is required |
|
| ||||||||
| component type allows to specify wire targets on references | Push teh getTargets() method from Reference to ComponentReference |
|
| ||||||||
| usage usage of not promoted references | Make sure the reference resolution follows what's described by the assembly spec |
|
| ||||||||
| SCA <anyAttribute.../> declarations should use namespace ##other rather than ##any | Update the xsd from OASIS |
| SCDL artifact resolution underspecified | Adjust the artifact resolution based on the proposal in this JIRA | TUSCANY-3079 |
| |||||
| Conflicting Specification of Values for Many-Valued StringProperties | Adjust the property value processing to conform to the new syntax, Can't have multiple properties with the same name |
| | Can Implementation change property values after instantiaion | No action is required |
| |||||
| Missing XSD for contributions | Update the xsd from OASIS. Update the Import/Export model to |
| |||||||||
| Clarify whether a Default Value for a Property must appear inthe componentType of an implementation | No action is required |
| |||||||||
| Permit intents and PolicySets on <interface/> elements | The policy model needs to be changed so that interface can have intents/policySets attached. |
| |||||||||
Component URI is not well described | Tuscany needs to support the structural URI based on this proposal |
|
| |||||||||
| Need to define Namespace handling for included Composites | Tuscany needs to adjust how the composite include is aggregated based on the proposal in this JIRA |
|
| ||||||||
| XSD definitions of Component Service and Component Referencehave unintended features |
|
|
| ||||||||
| WSDL extension should not be required for conversations | Make sure conversational intent is supported at interface and service |
| | Autowire at the domain level | Tuscany needs to decide if/how it will support the domain-level autowiring |
| |||||
| Autowire value for the logical domain composite | I think Tuscany is OK here as the autowire=false for the domain composite |
| |||||||||
| Unresolved bindings on references | Add the support for "componentName/serviceName/bindingName" as the wire target |
| |||||||||
SCA <anyAttribute.../> declarations should use namespace ##other rather than ##any | Update the xsd from OASIS, can we support OSOA and OASIS xsds? |
|
| |||||||||
| Can Implementation change property values after instantiaion | No action is required | | Component Type file name is too restrictive |
|
| ||||||
| SCA Composite Visibility | This seems to be a clarification by the spec ComponentType Properties should not have a source |
|
| ||||||||
| Missing XSD for contributions | Update the xsd from OASIS. Update the Import/Export model to |
|
| ||||||||
| Incorrect description of <Operation/> child elements inAssembly | I see this conflicts with http://www.osoa.org/jira/browse/POLICY-58 Policy-58 did win and operation elements are no longer required |
|
| ||||||||
| "SCA schema fixes requested for sca-core.xsd "SCA schema fixes requested for sca-core.xsd (based on OSOA site versions that may be copied to OASIS site)" |
|
|
| ||||||||
| Description elements in SCDL | Long-Running Request-Response Operations | Tuscany needs to support the proposal | Support documentation element in the model and processors |
| |||||||
| Confusing words in Section 5.3 relating to ConversationalIntent , Conversational support has gone | No schema or extension model definitions for contributions |
|
| ||||||||
| Compatability of component type allows to specify wire targets on references side files | Each implementation type has to decide how to support the componentType file | Push teh getTargets() method from Reference to ComponentReference |
| ||||||||
| Clarify whether a Default Value for a Property must appear inthe componentType of an implementation | No action is required Assembly Specification should not state what marks a Javainterface as Local |
|
| ||||||||
| ASSEMBLY-71 Implementation.composite pseudo-schema incorrect 39 | Permit intents and PolicySets on <interface/> elements | The policy model needs to be changed so that interface can have intents/policySets attached. |
|
| |||||||
| Conflicting Specification of Values for Many-Valued StringProperties | Autowire at the domain level | Tuscany needs to decide if/how it will support the domain-level autowiring | Adjust the property value processing to conform to the new syntax |
| |||||||
| WSDL extension should not be required for conversations | Make sure conversational intent is supported at interface and service |
| Conflicting domain-level <wire> deployments | Tuscany needs to implement the proposal | | XSD definitions of Component Service and Component Referencehave unintended features |
|
| |||
| Specification wording unclear on how local and remoteable interfaces are specified | Remotable is IDL specific |
| |||||||||
| Constraining Type talks about non-optional references but does not define what they are |
|
| |||||||||
| How to map WSDL 1.1. portType to WSDL 2.0 interface and vice versa? | Remove the wsdl2.0 specfics from sca namespace. Potentially add interface.wsdl2 under tuscany ns |
| |||||||||
| Language neutrality edits |
|
| |||||||||
Autowire value for the logical domain composite | I think Tuscany is OK here as the autowire=false for the domain composite |
|
| |||||||||
| for implentations.*'s fix attributes that should show qnames as values |
|
|
| ||||||||
| Allow multiple definitions.xml files | Tuscany should allow META-INF/definitions.xml from SCA contributions. These definitions become visible to the SCA domain |
|
| ||||||||
| | some smaller things we need to fix in the assembly specification |
|
|
| |||||||
| Need to clarify definition of Bidirectional Interfaces | Make sure Tuscany is consistent with the specified behavior |
| Composite Completeness | Tuscany needs to add more validations to ensure the completeness of the composite for implementaiton.composite |
|
| |||||
| No schema or extension model definitions for contributions |
|
| | Conflicting domain-level <wire> deployments | Tuscany needs to implement the proposal |
| |||||
| Identifying wire format and operation selection | Need to clarify definition of Bidirectional Interfaces | Make sure Tuscany is consistent with the specified behavior | add "wireFormat" and "operationSelector" for bindings |
| |||||||
| What is the default value for many and mustSupply on Properties? | remove "mustSupply" from <component> |
| Unresolved bindings on references | Add the support for "componentName/serviceName/bindingName" as the wire target |
|
| |||||
| Description elements in SCDL | Support documentation element in the model and processors |
| | SCA Composite Visibility | This seems to be a clarification by the spec |
| |||||
| Composite Completeness | Tuscany needs to add more validations to ensure the completeness of the composite for implementaiton.composite |
| |||||||||
| Compatability of component type side files | Each implementation type has to decide how to support the componentType file |
| |||||||||
| Allow multiple definitions.xml files | Tuscany should allow META-INF/definitions.xml from SCA contributions. These definitions become visible to the SCA domain |
| |||||||||
| Need for a Callback annotation for WSDL interface files | Tuscany needs to handle sca:callback extensibility elements in WSDL |
| |||||||||
| Component URI is not well described | Tuscany needs to support the structural URI based on this proposal |
| |||||||||
| SCDL artifact resolution underspecified | Adjust the artifact resolution based on the proposal in this JIRA |
| |||||||||
| Need to define Namespace handling for included Composites | Tuscany needs to adjust how the composite include is aggregated based on the proposal in this JIRA |
| |||||||||
| Incorrect description of <Operation/> child elements inAssembly | I see this conflicts with http://www.osoa.org/jira/browse/POLICY-58 |
| |||||||||
What is the default value for many and mustSupply on Properties? | remove "mustSupply" from <component> |
|
| |||||||||
| Specification wording unclear on how local and remoteable interfaces are specified | Remotable is IDL specific |
|
| ||||||||
| Constraining Type talks about non-optional references but does not define what they are |
|
|
| ||||||||
| Component Type file name is too restrictive Assembly has washed itself somewhat of ComponentType files Up to C&I to define what to do, BPEL has got rid of them, Tuscany should ignore for 2.x |
|
|
| ||||||||
| ComponentType Properties should not have a source |
|
|
| ||||||||
| Language neutrality edits |
|
|
| ||||||||
| Implementation.composite pseudo-schema incorrect |
|
|
| ||||||||
| Do we need appendix A (pseudo-schema)? | No action is required |
| | Long-Running Request-Response Operations | Tuscany needs to support the proposal |
| |||||
| Add a Section documenting naming conventions to the start ofthe SCA Assembly Specification | No action is required |
| Corrections to the contributions schema, sca-contribution.xml specify what is deployable We should use in our samples | | Corrections to the contributions schema | See ASSEMLY-28 |
|
| |||
| Duplicated atributes in sca-binding-sca.xsd and sca-implementation-composite.xsd | No action is required |
| "Section on ""Wire"" in Appendix is | | "Section on ""Wire"" in Appendix is Incorrect" | Tuscany already has the correct model, No action is required |
|
| |||
| Do we need appendix A (pseudo-schema)? | No action is required |
|
Java
OSOA - Tuscany 1.x (SCA_JavaAnnotationsAndAPIs_V100 +)
OASIS - sca-javacaa-1.1-spec-cd01
http://www.osoa.org/jira/browse/JAVA
How to map WSDL 1.1. portType to WSDL 2.0 interface and vice versa? | Remove the wsdl2.0 specfics from sca namespace. Potentially add interface.wsdl2 under tuscany ns |
|
| |||||||||
| Identifying wire format and operation selection | add "wireFormat" and "operationSelector" for bindings |
|
| ||||||||
| Duplicated atributes in sca-binding-sca.xsd and sca-implementation-composite.xsd | No action is required | ||||||||||
| OASIS JIRA | Description | Tuscany TODO | Tuscany JIRA | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Spurious cast() method definition in ComponentContext interface |
|
| |||||||||
| Constructor name information may not be available | Need for a Callback annotation for WSDL interface files | Tuscany needs to handle sca:callback extensibility elements in WSDL | Adjust the @Property/@Reference processor on CDI |
| |||||||
| Assembly Specification should not state what marks a Javainterface as Local | Java CAA spec does not contain the interface.java schema |
|
| ||||||||
| Add a Section documenting naming conventions to the start ofthe SCA Assembly Specification | No action is required Incorrect definition of the SCA JEE JSP Tag library |
|
| ||||||||
| Inconsistent use of a and an when referring to annotations |
|
| No @replace attribute for <wire> in OSOA spec | No action is required | | Normative references to SCA Spec docs point to v1.00 docs |
|
| |||
| No <value> subelement for property in OSOA spec, so ASM50028,ASM50029 in OASIS spec couldn't be tested for vtest code. | No action is required Missing word "type" for "return type" in CAA spec - sec 3.1 |
|
| ||||||||
| Incorrect description of @Scope annotation default | Make sure the scope is default to "COMPOSITE" if there is an @Conversational |
| Top level composite services/references are not included in the virtual domain composite | Adjust logic and tests | | Incorrect reference to "original request" |
| |
Policy
...
...
Should not say callback ID is passed in reference parameters
...
...
...
...
...
Incorrect code in section 6.7.2 example
...
...
...
...
...
SCA Spring C & I specification does not state the purpose of sca:composite element
...
Remove the sca:composite
...
...
...
...
Describe the concurrency model for each scope
...
...
...
...
...
SCA Spring Client and Implementation Specification uses an unacceptable namespace
...
Update the namespace based on the OASIS spec
...
...
...
...
When more than one interface with the same unqualified name used in the @Service annotation
...
...
...
...
...
SCA Java Specifications do not Adequately Define the ComponentType of a Java implementation
...
Check the compontType to see if it matches the rules defined by this proposal
...
...
...
...
Version requirements for SDO, JAXB and JAX-WS
...
...
...
...
...
@Callback annotation does not feature in section on Interfaces
...
...
...
...
...
Missing description of what the @EagerInit annotation does
...
...
...
...
...
@Reference annotation can also be used on a constructor parameter.
...
...
...
...
...
Incorrect examples of methods annotated @Init and @Destroy
...
...
...
...
...
Inconsistent method description for @Init and @Destroy annotations
...
Tuscany already validates the pattern
...
...
...
...
Incorrect generated service name
...
...
...
...
...
Clarify Request Scope lifetime
...
Remove the Request scope
...
...
...
...
annotations on parameters
...
@Reference, @Property can only be used for constructor parameters. Tuscany
may need to report violations
...
...
...
...
EJB remove method on EJBHome
...
...
OSOA - Tuscany 1.x (SCA_Policy_Framework_V100 +)
OASIS - sca-policy-11.1-spec-wd-10
http://www.osoa.org/jira/browse/POLICY
| OASIS JIRA | Description | Tuscany TODO | Tuscany JIRA | Conformance |
|---|---|---|---|---|---|
| Implicit addition of intents based on a service or reference's @requires list |
|
|
| |
| Include definition on 'conversational' intent as mentioned in SCA Assembly |
|
|
| |
| External mechanism for attaching intents or policySets |
|
|
| |
| Need Transaction Policy Spec |
|
|
| |
| Should qualifiable intents have a default qualifier |
|
|
| |
| Profile intent extension - provides other intents |
|
|
| |
| More direct, structural qualifier definition |
|
|
| |
| Security implementation policy should be validate-able by schema |
|
|
| |
| Need more precision on when policies in a policySet are in effect |
|
|
| |
| The URL for the location of the ws-policy.xsd is incorrect. |
|
|
| |
| Improve description of the overides available to the two different hierarchies in SCA |
|
|
| |
| Need Support for Mutually exclusive intents |
|
|
| |
| Fix SCA Policy schema complex types for Qualifier and PolicySet |
|
|
| |
| Infoset for policySet/@appliesTo |
|
|
| |
| Need a clear way to distinguish Implementation Intents from Interaction Intents |
|
|
| |
| How to configure policySets |
|
|
| |
| Policy algorithm gets required intents from what interfaces definitions/declarations? |
|
|
| |
| How do we tell what a policySet @provides? |
|
|
| |
| Wire validation rules have changed |
|
|
| |
| Clarify the handling of Intents |
|
|
| |
| Intents which conflict with binding configuration |
|
|
| |
| Remove <operation/> elements from the specification |
|
|
| |
| Limit policySet attachment to bindings |
|
|
| |
| Clarify scope of ordered intent | Add "ordered" intent support |
|
| |
| How are mayProvide intents on bindings satisfied |
|
|
| |
| intents names defined by SCA should be defined using camel case |
|
|
|
Implementations
Implementation-java
OSOA - Tuscany 1.x (SCA_JavaAnnotationsAndAPIs_V100 +)
OASIS - sca-javacaa-1.1-spec-cd01
http://www.osoa.org/jira/browse/JAVA
| OASIS JIRA | Description | Tuscany TODO | Tuscany JIRA | Conformance |
|---|---|---|---|---|---|
| EJB remove method on EJBHome |
|
|
| |
| annotations on parameters | @Reference, @Property can only be used for constructor parameters. Tuscany |
|
| |
| Clarify Request Scope lifetime | Remove the Request scope |
| ||
| Incorrect generated service name |
|
|
| |
| Inconsistent method description for @Init and @Destroy annotations | Tuscany already validates the pattern |
|
| |
| Incorrect examples of methods annotated @Init and @Destroy |
|
|
| |
| @Reference annotation can also be used on a constructor parameter. |
|
|
| |
| Missing description of what the @EagerInit annotation does |
|
|
| |
| @Callback annotation does not feature in section on Interfaces |
|
|
| |
| Version requirements for SDO, JAXB and JAX-WS |
|
|
| |
| SCA Java Specifications do not Adequately Define the ComponentType of a Java implementation | Check the compontType to see if it matches the rules defined by this proposal |
|
| |
| When more than one interface with the same unqualified name used in the @Service annotation |
|
|
| |
| SCA Spring Client and Implementation Specification uses an unacceptable namespace | Update the namespace based on the OASIS spec |
|
| |
| Describe the concurrency model for each scope |
|
|
| |
| SCA Spring C & I specification does not state the purpose of sca:composite element | Remove the sca:composite |
|
| |
| Incorrect code in section 6.7.2 example |
|
|
| |
| Should not say callback ID is passed in reference parameters |
|
|
| |
| Incorrect reference to "original request" |
|
|
| |
| Incorrect description of @Scope annotation default | Make sure the scope is default to "COMPOSITE" if there is an @Conversational |
|
| |
| Missing word "type" for "return type" in CAA spec - sec 3.1 |
|
|
| |
| Normative references to SCA Spec docs point to v1.00 docs |
|
|
| |
| Inconsistent use of a and an when referring to annotations |
|
|
| |
| Incorrect definition of the SCA JEE JSP Tag library |
|
|
| |
| Java CAA spec does not contain the interface.java schema |
|
|
| |
| Spurious cast() method definition in ComponentContext interface |
|
|
| |
| Constructor name information may not be available | Adjust the @Property/@Reference processor on CDI |
|
| |
| N/A | Support for @Remote attribute in in <interface.java/> |
| TUSCANY-3290 |
|
| N/A | Illegal annotations in a service interface class |
| TUSCANY-3289 |
|
| N/A | Support JAX-WS Client Asynchronous API for a Synchronous Service as described in Java CAA |
| TUSCANY-3294 |
|
| N/A | Update SCA Annotation definitions in sca-api to match the OASIS 1.1 Java CAA Specification |
| TUSCANY-3293 |
|
| N/A | Verify @Service compliance with latest OASIS Java 1.1 draft spec |
| TUSCANY-3300 |
|
| N/A | Verify @Property compliance with latest OASIS Java 1.1 draft spec |
| TUSCANY-3301 |
|
Bindings
http://www.osoa.org/jira/browse/BINDINGS
Binding-jms
| OASIS JIRA | Description | Tuscany TODO | Tuscany JIRA | Conformance |
|---|---|---|---|---|---|
| JMSDeliveryMode, JMSTimeToLive and JMSPriority defined as types different from what the JMS specification uses. |
|
|
| |
| JMS bindingType and atLeastOne intent overlaps with setting JMSDeliveryMode |
|
|
| |
| JMS bindingType and conversation intent |
|
|
| |
| JMS bindingType and ordered intent - clarification needed |
|
|
| |
| Are JMS message selectors supported? |
|
|
| |
| What namespace(s) do we use for each binding? |
|
|
| |
| Rules for Binding compatibility |
|
|
| |
| Clarify the rules on which queues are used for responses and callbacks |
|
|
| |
| JMS binding URI should follow JMS IRI scheme submitted to IETF |
|
|
| |
| JMS binding pseudo-schemas inconsistent with assembly |
|
|
| |
| Properties on Bindings |
|
|
| |
| Normative reference consistency |
|
|
| |
| What is a "plain name" for a connection factories or activation specs, and how is one distinguished from a JNDI name? |
|
|
| |
| Document the attributes inherited from the base definition provided by SCA Assembly specification. |
|
|
| |
| Correlation property names are odd, and the space of options is not extensible. |
|
|
| |
| Clarify default function selection and data binding behavior |
|
|
| |
| Allow topics anywhere that queues can be used |
|
|
| |
| Clarify use of URI vs. uri |
|
|
| |
| Clarify rules around combination of destination, CF and AS elements |
|
|
| |
| How are mayProvide intents on bindings satisfied |
|
|
| |
| Conformance statement numbering |
|
|
|
Binding-ws
| OASIS JIRA | Description | Tuscany TODO | Tuscany JIRA | Conformance |
|---|---|---|---|---|---|
| How should SCA callback semantics be carried over Web Services? |
|
|
| |
| portType referred to inconsistently throughout specification |
|
|
| |
| No bindingType for binding.ws |
|
|
| |
| Use of wsdli:wsdlLocation does not match WSDL 2.0 specification |
|
|
| |
| Rules for WSDL generation create invalid WSDL by using "/" where it is not allowed. |
|
|
| |
| What namespace(s) do we use for each binding? |
|
|
| |
| Namespace/location for WS-Addressing is incorrect in WebService binding spec/XSD |
|
|
| |
| binding.ws reference to assembly spec for interface mapping is incorrect |
|
|
| |
| Rules for Binding compatibility |
|
|
|
Policy
OSOA - Tuscany 1.x (SCA_Policy_Framework_V100 +)
OASIS - sca-policy-11.1-spec-wd-10
http://www.osoa.org/jira/browse/POLICY
OASIS JIRA | Description | Action |
|---|---|---|
intents names defined by SCA should be defined using camel case |
| |
How are mayProvide intents on bindings satisfied |
| |
Clarify scope of ordered intent |
| |
Limit policySet attachment to bindings |
| |
Remove <operation/> elements from the specification |
| |
Intents which conflict with binding configuration |
| |
Clarify the handling of Intents |
| |
Wire validation rules have changed |
| |
How do we tell what a policySet @provides? |
| |
Policy algorithm gets required intents from what interfaces definitions/declarations? |
| |
How to configure policySets |
| |
Need a clear way to distinguish Implementation Intents from Interaction Intents |
| |
Infoset for policySet/@appliesTo |
| |
Fix SCA Policy schema complex types for Qualifier and PolicySet |
| |
Need Support for Mutually exclusive intents |
| |
Improve description of the overides available to the two different hierarchies in SCA |
| |
The URL for the location of the ws-policy.xsd is incorrect. |
| |
Need more precision on when policies in a policySet are in effect |
| |
Security implementation policy should be validate-able by schema |
| |
More direct, structural qualifier definition |
| |
Profile intent extension - provides other intents |
| |
Should qualifiable intents have a default qualifier |
| |
Need Transaction Policy Spec |
| |
External mechanism for attaching intents or policySets |
| |
Include definition on 'conversational' intent as mentioned in SCA Assembly |
| |
Implicit addition of intents based on a service or reference's @requires list |
|
Bindings
http://www.osoa.org/jira/browse/BINDINGS
OASIS JIRA | Description | Action | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Clarify use of URI vs. uri |
| |||||||||
Does WSDL binding take precedend over policy intents |
| |||||||||
Allow topics anywhere that queues can be used |
| |||||||||
Clarify default function selection and data binding behavior |
| |||||||||
Correlation property names are odd, and the space of options is not extensible. |
| |||||||||
JMS binding pseudo-schemas inconsistent with assembly |
| |||||||||
JMS binding URI should follow JMS IRI scheme submitted to IETF | ||||||||||
| Web Service binding should allow #wsdl.binding with reference targets |
|
|
| ||||||
| @wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs |
|
| Clarify the rules on which queues are used for responses and callbacks | ||||||
| Properties on Bindings |
|
| Rules for Binding compatibility | ||||||
| Normative reference consistency |
|
| binding.ws reference to assembly spec for interface mapping is incorrect | ||||||
| Namespace/location for WS-Addressing is incorrect in WebService binding spec/XSD |
| Document the attributes inherited from the base definition provided by SCA Assembly specification. |
|
|
| What namespace(s) do we use for each binding? | |||
| Does WSDL binding take precedend over policy intents |
|
| Rules for WSDL generation create invalid WSDL by using "/" where it is not allowed. | ||||||
| Clarify use of URI vs. uri |
| Use of wsdli:wsdlLocation does not match WSDL 2.0 specification |
| ||||||
No bindingType for binding.ws |
| |||||||||
JMS bindingType and conversation intent |
| |||||||||
JMS bindingType and atLeastOne intent overlaps with setting JMSDeliveryMode |
| |||||||||
portType referred to inconsistently throughout specification |
| |||||||||
JMSDeliveryMode, JMSTimeToLive and JMSPriority defined as types different from what the JMS specification uses. |
|
BPEL
http://www.osoa.org/jira/browse/BPEL
BPEL
http://www.osoa.org/jira/browse/BPEL
| OASIS JIRA | Description | Tuscany TODO | Tuscany JIRA | Conformance | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| support for BPEL4WS 1.1 |
|
|
|
| Does the spec allow a componentType side file |
|
|
| ||
| Correlation disagreement between SCA and BPEL |
|
|
| |||||||
| SCA-BPEL XML Namespaces |
|
|
| |||||||
| test issue please ignore |
|
|
| |||||||
| ComponentType should not contain implementation.bpel |
|
|
| |||||||
OASIS JIRA | Description | Action | |||||||||
SCA-BPEL spec can not require bpel:mustUnderstand to be true |
| ||||||||||
SCA-BPEL XML Schema |
| ||||||||||
Allow Component Type side file to override defaults for service/reference | |||||||||||
| Allow sca-aware processes to specify everything that can be specified in a CT side file |
|
|
| |||||||
| BPEL-13 ComponentType should not contain implementation.bpel 17 | Allow Component Type side file to override defaults for service/reference |
|
| test issue please ignore | ||||||
| SCA-BPEL XML Namespaces Schema |
|
| Correlation disagreement between SCA and BPEL | |||||||
| Does the spec allow a componentType side file |
| SCA-BPEL spec can not require bpel:mustUnderstand to be true |
|
| support for BPEL4WS 1.1 |
|