Re: Requirements and defintions documents

[Henry Lowe <hlowe@omg.org>]

Hi all,

Here are my comments on the set of requirements sent out 
Tuesday.  I will try to comment on the definitions document 
later today.  Due to being at an OMG meeting, I haven't been 
able to put as much time into them as I'd like.  Also, I 
am trying to get one or perhaps more of the OMG members 
to participate in ebXML, though it probably won't happen 
for this coming meeting due short time scale.

A few general comments first:

1. I think it would be useful if our requirements were 
   separated into packaging and transport sections.  I'm 
   not saying anything is out of scope, but it would 
   make it easier to see who is supposed to be doing 
   what; 

2. Some of the requirements that are not so designated 
   are really optional -- we should probably go thru and 
   agree which are mandatory and which optional; and 

3. I have the feeling that not all of the requirements 
   are at the same level for transport -- some seem to 
   be fairly low level whereas others are high level. 
   Unfortunately, I don't have time to figure out how 
   to categorize the requirements (if that's what we 
   need) and put each in its proper place.  This will 
   be particularly usedful in evaluating technologies 
   for transport services and packaging services (assuming 
   they are not necessarily the same).

Specific comments (sequential): 

1.4 Some of the examples given are more than just a protocol, 
   in particular, CORBA and MQSeries includes service APIs
   (I'm not familiar enough with JMQ, JMS and MSMQ to say;
   I believe HTTP and SMTP are just protocols -- at least 
   they were originally).  Also, not all of these are open;
   should we be focusing on open services and protocols?

1.5 I would suggest we mind use "unambiguous" instead of 
   "unique" as it's probably all that's required and is easier 
   to do.

1.7 thru 1.10 These requirements are services that are normally 
   provided by a queuing service.  However, the requirement here 
   is being put on the envelope which is, I believe, a packaging 
   concern.  Is this necessary as a packing requirement?  It 
   definitely is for a queue based transport which we want -- see 
   long term transactions in requirements.

2.2.e We probably shouldn't use the term "abnormal errors" (all 
   errors are abnormal behavior) and what does "fell over" mean?

2.4 and 2.5 I believe would be better placed in clause 4 which deals 
   with security and signatures in particular.

6.0 In the text before 6.1, is this saying that the following are 
   requirements for dynamic (vs static, i.e., designated or selected 
   before the transaction is begun) QoS?  If so, do we have any 
   static QoS requirements?  [Selecting QoS staticall is probably 
   more efficient opertionally than dynamic.]

6.1.a and 6.1.b  Aren't these definitions?

6.2 is part definition part requirment -- should we separate them?

6.2.e  The requirement doesn't seem to be complete -- an instance 
   of what?  I'd guess this is a typo.

7.1 How are "black boxes" relevant to interoperability?

7.2 I would suggest we add an item (c) as follows:
   c) the language used for implementation of systems and applications.

8.1 I would suggest we specify when the service becomes unavailable, 
   i.e., before the start of the transaction or after the start of the 
   transaction, as this probably makes a lot of difference in the 
   capability we are requiring of the system.  Of course, it could be 
   that we require both -- if this is the case, I would suggest we 
   state this explicitly.


Best regards,
Henry
---------------------------------------------
At 04:53 PM 01/11/2000 -0800, David Burdett wrote:
>I attach updated versions of the requirements and defintions documents. You
>will find quite a few changes since I received quite a lot of feedback. Some
>of the suggestions came in emails sent privately to me so not everyone will
>be able to trace the original unless those individuals to whom I've posted a
>reply want to forward my reply to the list.
>
>There are three pdf files:
>*      Version 5 of the requirements (with changes highlighted)
> <<ebXML Transport Requirements 5.pdf>> 
>*      the same as the previous item but with no changes highlighted - this
>is much easier to read
> <<ebXML Transport Requirements 5 without changes highlighted.pdf>> 
>*      and the ebXML Transport definitions document that is unchanged but
>I'm including in case someone new to the list hasn't seen it yet.
> <<ebXML Transport Definitions 1.pdf>> 
>
>We really need to tie these down and, after discussion with Rik, he's
>suggesting that we finally freeze the requirements document by 5PM PST this
>Thursday.
>
>David
>
>Advanced Technology, CommerceOne
>1600 Riviera Ave, Suite 200, Walnut Creek, CA 94596, USA
>Tel: +1 (925) 941 4422 or +1 (650) 623 2888; 
>mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>
>
>
>