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: Comment on David's Expanded requirements


David, and all,

	David I think your list is a very good start and clarifies several
of the vague points we made and had wanted to follow up on the Friday if we
had been given the time.

	My comments concern section 9 Workflow of business documents, point
3 error handling,  I do not think this is part of workflow I am not sure
exactly where it fits, but I would propose we extend reliable messaging to
cover error handling and processing as I can identify several levels of
errors that we may have to handle or report.  The following are my initial
thoughts and ideas, I hope we can add to them and this is a starter to get
the collective ideas going.

	We already define the failure to deliver in the reliable messaging
section.  The following list is in no order and I do not think complete.
	1) Message structural errors e.g. we may be passed insufficient
details to create a valid package.
	2) We send a valid message that the other party will not accept e.g.
it cannot handle the message type.
	3) The application cannot process the message e.g. too much/little
information in the message.
	4) The actual data content is not processable e.g. an alphabetical
product number when the application accepts only numeric values.

	I think there must also be a link to the Quality of service section
on transaction status inquiry (Section 6 point 4) so that both parties can
discover why a message failed,  who does the query or require the response
depends on how the transaction was being handled and how initiated it.

	I am aware that some similar work is going on in the IETF (Rik and
others on EDIINT) anything to add Rik?


	Just to start a totally new thread of comments, I think we need to
define some common terminology for us to use, are we discussing messages,
components, parts, XML documents, etc.   As a start are we going to deliver
a "Package" and a "Package" may contain a number or "Documents" and each
"Document" is composed of a collection of "XML Components".  From my
background in EDI I equate "Document" to "Message" and approximately equal
to a paper document.  Comments and suggestions please.

	Final comment, should we use attachments or in-line email comments
when do this sort of work?  

Ian Jones

PP E3A
84-85 Adam Street, Cardiff, CF24 2XF
> *Tel:  +44 (0)29 2072 4063
> * Fax: +44 (0)29 2046 1752
Email: ian.c.jones@bt.com  
 



[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