sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Proposed resolutions for issues - overview updated
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 17 Dec 2009 10:58:04 +0000
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]