OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposed resolutions for issues - overview updated



Folks,

Here's an updated summary of the open issues for the Bindings TC:

http://www.osoa.org/jira/browse/BINDINGS-107 What is the purpose of definitions/binding element?
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200911/msg00035.html
Summary:
Use of bindings element in definitions file is not necessary, some agreement on just removing all mention of it from bindings specs, reflected in the proposed resolution.  This would also apply to BINDINGS-108 when opened.


http://www.osoa.org/jira/browse/BINDINGS-96 BJM60012 and BJM60013 conflict
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200912/msg00008.html
Summary:
These normative statements conflict because the conditions under which they apply overlap.

The proposal is to remove the overlap and simplify things by only using scaCallbackDestination as the callback destination for request/response operations, where the JMSReplyTo is already used for the reply destination, and use JMSReplyTo as the callback destination for oneway operations.

http://www.osoa.org/jira/browse/BINDINGS-94 scaCallbackDestination destination name unclear
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200912/msg00009.html
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200912/msg00020.html
Summary:
Clarify the syntax of the destination "name" that appears in the scaCallbackDestination user property - proposal is that this must be a JMS URI. Resolution depends on some other changes proposed for BINDINGS-96.

http://www.osoa.org/jira/browse/BINDINGS-95 BJM30032 and BJM30035 conflict
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200911/msg00010.html
Summary:
These normative statements conflict because the conditions under which they apply overlap.
The proposal is to make the statements more specific by including additional conditions under which they apply which were previously implicit from the context of the statements; it covers issues 95, 105 and 106 which all affect the same overall set of statements.
Linked email provides two alternatives: modify existing statements to ensure conditions on the statements are exclusive, or replace all the statements with single statements that define behaviour via a prioritised list of conditions, so far preference seems to be towards the latter.


http://www.osoa.org/jira/browse/BINDINGS-105 BJM30025 has no normative keyword
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200911/msg00010.html
Summary:
This issue overlaps with BINDINGS-95, see above


http://www.osoa.org/jira/browse/BINDINGS-106 BJM30027 has no normative keyword
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200911/msg00010.html
Summary:
This issue overlaps with BINDINGS-95, see above.


http://www.osoa.org/jira/browse/BINDINGS-101 Opaque references - need for a terminology list?
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200912/msg00013.html
Latest email: http://lists.oasis-open.org/archives/sca-bindings/200912/msg00015.html
Summary:

Update non-normative text in abstract, introduction and policy section to link to assembly and policy specs.
Create editorial actions to check and update web service and JMS binding specs in a similar fashion.

http://www.osoa.org/jira/browse/BINDINGS-103  optional used in normative statement
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200911/msg00037.html
Summary:
"optional" is used in a normative statement without normative meaning.
Proposal is to replace the use of "optional" and ensure that the normative statements are clear, along with a schema update to make the schema reflect the intended optionality of the jndiName attribute.


http://www.osoa.org/jira/browse/BINDINGS-104  Expected @create attribute value not clear in some normative statements
Proposed resolution in email
http://lists.oasis-open.org/archives/sca-bindings/200912/msg00019.html
Summary:
Another case where statements overlap due to omission of contextual information.
Proposal is to explicitly state the conditions in the normative statements that previously were implicit from context.


http://www.osoa.org/jira/browse/BINDINGS-102 Need to specify all valid enumerations for @create attribute and others
No proposed resolution
Summary:
I'm in the process of checking this for the JCA binding, and there's one enumeration I'm stuck on which is:

<resAuth>container|application</resAuth>


Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair, AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]