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