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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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 - 7.13.5.4 - 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.
7.13.5.5.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."
7.13.5.7 - According to the text of section 7.13.5.5, 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 7.13.5.5.  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  7.13.5.5.
7.13.5.8 - 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


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC