[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Final batch of outstanding issues from Tokyo - I Hope!!
Fellows, the following 3 issues I hope will conclude the Tokyo version 0.8 follow up I believe we have already addressed the first 2 and the 3rd is a unilateral proposal to amalgamate lost of small queries that will have been superseded. I'll double check that we have looked at all the issue in the database over the holiday and then I'll work with Chris to capture and structure all the new things that we have been discussing. This will enable us to Identify any issue we need for the London F2F. #### Issue 20 Title - Timeout & retry definitions Detail - 7.12 - The Timeout and RetryInterval parameters have different semantics as described later in this document. However, that difference is not made clear in this table. Recommend RetryInterval definition be changed to "Wait time between receiving notification of a transport error and sending a retry. * Integer value specifying number of seconds. * After any error response is received, the Sender SHALL wait for the specified time before sending a retry document." If the intended semantics of RetryInterval require that documents not be send more often than the specified interval (requiring the Sender to wait for a timeout, declaring that status and then beginning a wait for RetryInterval), that could be described by changing my words above to include a bullet such as "* Notification of a transport error includes detecting an expired timeout while awaiting a response." Proposal - Section has been reworked by Chris and David make comment accepted or reject or see Issue 22 below for superseded proposal. Resolution - Response By - January 4 #### Issue 21 Title - Error reporting Detail - 188.8.131.52 - Either the Description element should be allowed to repeat (providing multiple descriptions of the error in various locales) or a Normal message should specify the preferred locale for Error messages. Without this, the Description content is not going to be useful with multiple, interoperating systems. 184.108.40.206.2 - How does this RefToMessageId relate to the one in MessageData? Since we aren't attempting to handle an Error response covering multiple messages in error (right?), change the last sentence to be "This must be present [and have the same value as the RefToMessageId in the MessageData element of the Header] if a MessageId can be identified in the message in error." 220.127.116.11 - According to the text of section 18.104.22.168, we've got a meaning for a minimum of one ErrorLocation element. Either change "ErrorLocation*" to "ErrorLocation+" (requiring one or more such element) or define the meaning of zero ErrorLocation elements in section 22.214.171.124. For the second resolution, add "If no ErrorLocation element is provided, no information about the specific location of the error is available. When a MessageId can be determined from the message in error, the ebXMLError must contain one or more ErrorLocation elements." to the end of section 126.96.36.199. 188.8.131.52 - Are the two "narrative" types of information contained in the Description element or the ErrorCode? Replace "that immediately follows the error code" with "beginning the Description element" on line 1049. And, replace "that follow the narrative" with "that follow the narrative (completing the Description)" on line 1051. Suggest that these two types of bullets would not appear. Proposal - David B. to investigate and lead any appropriate actions. Resolution - Response By - January 4 #### Issue 22 Title - Errors and change request on schemas, DTD's and examples Detail - Several comments were raised on the DTD's, schema and examples which have now been superseded by new versions Proposal - Create a new resolution/disposition type of superseded and mark all outstanding comments as such due to the changes made since the original v0.21 makes tracking difficult. Also invite the original commenters to review the revised section once we have a new candidate version. Resolution - Response By - January 4 Ian Jones E-Commerce Engineer p.s. Happy Holidays
Powered by eList eXpress LLC