[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Requirement doc
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:email@example.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
Powered by eList eXpress LLC