RE: Comments on the Requirements

[David Burdett <david.burdett@commerceone.com>]

Hi

I'm replying to this email rather than the earlier ones. See comments below
marked with ##

David

-----Original Message-----
From: Jerry L. Brown [mailto:jerry.brown@sabre.com]
Sent: Friday, January 07, 2000 11:40 AM
To: Henry Lowe
Cc: ebXML-Transport
Subject: Re: Comments on the Requirements


Henry,
Sure I'll try and explain.
1. a) in the case of multiple documents that are directly related, a method
of sequencing must be possible.  (May be a point in 5  2))

Could you clarify what you mean by "sequencing", e.g., sequence
numbers on docs?

In the conversation of a reservation transaction we may have one or multiple
exchanges of messages(documents).  We currently have a way to say this is
message one, two or three etc. of the conversation.  Therefore, if we say
this is message three of the conversation the application can come back and
say hold it, we never got message two.  An analogy I guess this would almost
be like sending a document page at a time.
##I can think of a number of scenarios under this and I'm not sure which you
mean. For example:

Do you mean ...

FIRST		SECOND	PURPOSE
PARTY		PARTY
MsgP1	-->	  		First part of message, sent separately from
MsgP2	-->	  		Second part of message, sent separately from
MsgP3 -->	  		Third part of message
	<--	RespP1	Response to MsgP1, sent separately from
	<--	RespP2	Response to MsgP2, sent separately from
	<--	RespP3	Response to MsgP3, sent separately from

... or do you mean ...

FIRST		SECOND	PURPOSE
PARTY		PARTY
MsgP1	-->	  		First part of message
	<--	RespP1	Response to MsgP1
MsgP2	-->	  		Second part of message, reply to RespP1
	<--	RespP2	Response to MsgP2
MsgP3 -->	  		Third part of message, reply to RespP1
	<--	RespP3	Response to MsgP3

... or both?

In the first example MsgP1/2/3 could all be sent in the same wrapper, and
identified as being in a sequence. Although if they must be processed in a
specific sequence then it perhaps RespP2 should be a response to MsgP2 AND
MsgP1.

Either way I think there is a need for both.##


****************************************************************************
********************************

10. 1)
Scenarios ­ Provide an element within the transport packaging envelope
that indicates to the receiving fronted device that specific business
scenarios and dialogues are possible within this set of message
exchanges.

Is this a workflow sort of thing?

Yes it is a workflow sort of thing however it goes a little beyond that.  It
really is a place to say up front that this is the kind of work we will be
doing within this series of messages and if you can't play ball then tell me
right now.  This needs to be done in the as a part of the package since the
contents would not know what to do with the inbound request when it was
received.

##I agree, although I think that using a well identified name or code (e.g.
a URN) can be used to indicate the sequence that would be followed as
defined elsewhere, e.g. in a specification. Do you, though, think there is
benefit in being able to express the sequence in which you want to exchange
documents dynamically by expressing the types and sequences in which
documents are exchanged?##
****************************************************************************
********************************

Hope this help.
Thanks...
Jerry

Henry Lowe wrote:

> Jerry,
>
> See below:
>
> At 01:10 PM 01/06/2000 -0600, Jerry L. Brown wrote:
> >All,
> >Sorry to be so late in participation but I did manage to have vacation
> >the entire month of December.  But getting back in the thick of things,
> >here are some comments I have toward the requirement document.  Some
> >comments may be duplicated of if they need further explanation please
> >let me know.  These are by far not the only requirements that we may
> >need from the aspect of the Travel Industry point of view.  I did notice
> >that the requirements has a "document flavor" in terms of the Internet
> >world so as not to confuse anyone where possible I'll try and keep our
> >Travel Industry specific terms generic and from a "document" point of
> >view.  My comments are as follow:
> >
> >1. a) in the case of multiple documents that are directly related, a
> >method of sequencing must be possible.  (May be a point in 5  2))
>
> Could you clarify what you mean by "sequencing", e.g., sequence
> numbers on docs?
>
> >
> >2. e) a distinction must be made between system errors and application
> >errors.  For example being unable to fulfill a request due to
> >insufficient data to process or a lack product vs. system down,
> >interrupt condition.
>
> Yep!
>
> >
> >3. 3) envelope needs to allow for routing hops or multiple addresses.
> >Not to be confused with broadcast addressing.
>
> I think David already has this covered.
>
> >
> >10. 1)
> >Scenarios ­ Provide an element within the transport packaging envelope
> >that indicates to the receiving front-end device that specific business
> >scenarios and dialogues are possible within this set of message
> >exchanges.
>
> Is this a workflow sort of thing?
>
> Best regards,
> Henry