[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New proposed issues 1/5 - 1/11
|
Three new issues sent in since the last call listed below.
Please let me and the list know if any were missed. Regards, Marc g Proposed-01 - CloseSequence element is inconsistent Proposed-02 - Alternative approach for MaxMessage Proposed-03 - Acknowledgement Interval in
CreateSequenceResponse ------------- Proposed-01 Title - CloseSequence element is inconsistent Description - All other references to Sequence identifiers
is by an element, using a reference to the global wsrm:Identifier element. The
CreateSequence element uses an attribute, and defines it inline. Justification - While not a critical problem, the schema
should be consistent. Origin: Matthew Lovett <MLOVETT@uk.ibm.com> http://lists.oasis-open.org/archives/ws-rx/200601/msg00045.html Target - core / schema Type: design Proposal: Replace the attribute with a reference to the
wsrm:Identifier element within the CreateSequence element: Update the CloseSequence on line 372 (in wd 08), and the
following description. The new example should be: <wsrm:CloseSequence ...> <wsrm:Identifier ...> xs:anyURI
</wsrm:Identifier> ... </wsrm:CloseSequence> and the description need to be changed to include the new
element and the extensibility points. ------------- Proposed-02 Title - Alternative approach for MaxMessage Description - We solved the issue of some platforms not
having a native unsigned long by adding a MaxMessageNumber to Policy.
Another simpler approach would be to use max(signed long) as the limit,
and ensure that all implementations can support this. Origin: Paul Fremantle <paul@wso2.com> http://lists.oasis-open.org/archives/ws-rx/200601/msg00046.html Justification - This is not a critical issue, but this is
a simpler approach, with fewer moving parts. Target - core / design Type: design Proposal: Policy: Remove lines 97-100 plus editorial fixup of following
para. Remove line 114 Remove line 130-134 Core: Update line 465 to state new limit. Add a schema restriction on line 870 ------------- Proposed-03 Title - Acknowledgement Interval in CreateSequenceResponse Description - Propose moving AI from Policy to the
CreateSequenceResponse Justification - AcknowledgementInterval is not constraint
or feature of an endpoint, it is a protocol parameter of a given sequence. Moving it out of policy has a number of benefits. It
reduces the reliance on Policy and WSDL for simple devices, allowing them to
ascertain this value without supporting either of those standards. It makes it clear what the ack interval is for any
sequence. Further it seems unrealistic that a service would be chosen on the
basis of AckInterval. Origin: Paul Fremantle <paul@wso2.com> http://lists.oasis-open.org/archives/ws-rx/200601/msg00048.html Target - core / design Type: design Proposal: Modifications to the WSRM spec - Based on WD8 After line 302 insert: <wsrm:AcknowledgementInterval
Milliseconds="xs:unsignedLong" ... /> ? After line 326 Insert: /wsrm:CreateSequenceResponse/wsrm:AcknowledgementInterval This element, if present, specifies the duration after
which the RM Destination will transmit an acknowledgement. If omitted,
there is no implied value. /wsrm:CreateSequenceResponse/wsrm:AcknowledgementInterval/@Milliseconds The acknowledgement interval, specified in milliseconds. Changes to Policy document based on WD3. Remove lines 101-108 Remove line 113 Remove lines 125-129 Remove line 164 (AI example) At line 179 Remove text: "Line (13) indicates the RM
Destination may buffer acknowledgements for up to two-tenths of a second." |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]