RE: Requirement doc

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

Folks
 
Nikola made some suggested changes to the Overview & Requirements document.
Some were just typos. Also Dick made some comments on how repositories
worked.
 
Anyway I attach:
1. Nikola's list of comments annotated with comments against each one, ad
2. An updated version of the Overview & Requirements spec (version 0.91)
including Nikola's and Dick's comments
 
Regards
 
David
 
 

-----Original Message-----
From: Nikola Stojanovic [mailto:nstojano@cjds.com]
Sent: Friday, February 18, 2000 12:43 PM
To: David Burdett
Subject: Requirement doc


David,
Here are shorts of mine items. Would you mind that we do it over the phone
or maybe using NetMeeting?
Nikola
 
> 1) Sequence of msgs, ... 4.2 d) ?
 .. changed to read " the correct sequence in which related message are sent
can be identified"
> 2) Not, implies, if then else, operators for propositional logic?
 .. see also item 23. This is covered by a combination of Alternative,
Conditional, Parallel and Concurrent
> 3) 6 save, check => Checked OK.
.. Add another example where you do request, no ack, then checked OK between
figures 8 and 9
> 4) TR&P consistently.
.. Fixed section 3 also changed wording.
> 5) line to Message Policy repository.
.. added dashed line from "Transport, Routing & PAckaging" to "messaging
policy repository"
> 6) Extensibility of msg format and protocol itself.
.. added in new requirement for protocol extensibility
> 7) Integration server is abstraction and could be decomposed.
.. see comment in section 3
> 8) Messages globally unique?
.. clarified definition in 4.1 item 5
> 9) Errors in validation of msg XML format? Errors in sequencing?
.. clarified section 4.2 - added new items d) & f)
> 10) 4.3 5) ? Also, start numbering bullets with 1).
.. Fixed
> 11) Time stamps (universal vs. local)
.. all timestamps should be in universal time
> 12) 4.5 2) Linked how? Grouped?
.. clarified wording in section 4.5 item 2, also allowd references from one
message to the previous message that that caused the Message to be generated
it
> 13) 4.6 3) If not ACID it might be gone after checked.
.. A two phase commit is not normally needed.
> 14) 4.7 4) instead of PC -> something smaller or just not say PC.
.. changed "simple PC" to a "very simple device"
> 15) 4.8 Always consistent state. Like Rollback or Commit of ACID.
.. Enforcment of rollback will be dependent on the particular business
process that is being supported.
> 16) 4.1 1) Document Exchange instead of Transaction.
.. clarified wording of 4.1.1
> 17) Errors in a Message or while saving, processing, ... a Msg
.. covered by section 4.2 item 2.g
> 18) 5.1.3 Party could be a Software Agent?
.. added software agent as an example
> 19) Swap 5.1.6 and 5.1.7? Or, what is the structure of a Msg and its
parts?
.. agreed
> List them sequentially top down.
> 20) 5.1.11 Has to be persistent (saved)? Maybe doesn't care about audit?
.. Make saving in persistent storage a recommendation.
> 21) I kind of don't like Request / Exchange / Response separation. Dialog.
.. Current requirements make exchange and response message optional. Need to
make sure covered in the eventual specification
> 22) Service / Sub-Service definitions, ... are more for BP group? TR&P
just transfers Service Definition Names (IDs)?
.. The services within a sub-service need to be defined by the Business
Process Group. However if the dependencies and optionality can be expressed
as, for example, an XML document then it should be possible for the XML
Messaging system to check that the services have been executed in the
correct sequence.
> 23) 5.2.4 Alternative - OR or XOR?
.. XOR, see also item 2 above
> 24) 5.3.3 Period between which events?
.. clarified the wording
 
-- Various mistypos, grammar, ...

ebXML TR&P Overview & Requirements (v 0-91).pdf