Re: Comments on the Requirements

["Jerry L. Brown" <jerry.brown@sabre.com>]

David,
I'd say your second example is just about right on with our current processes.
We exchange messages in a logical order and and sequence.  If these messages get
out of order it poses a problem for us to continue since that logic is broken.
Thanks..
Jerry

David Burdett wrote:

> 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