Some comments for the requirements doc.

[Sazi Temel <sazi.temel@bea.com>]

Peter,
Thanks for creating the requirement doc. I know it is still a on going work
and not a first draft yet.. but here are my comments so far..

--Sazi

Lines:		-
Comment:	I think we should remove all the editorial comments from the doc
and write it as a draft version. We can still have the editorial comments
in a separate doc with line-numbers and comments.

Lines:		Page 1: 9 - 10
Comment: 	What is the policy of OASIS regarding the copyright of the
technical doc created by the OASIS technical committees? Are there any
OASIS document formats and templates to use?

Lines:		Page 1: 29
Comment:	they are (replace with there are, typo?)

Lines:		Page 2: 31
Comment:	Does demarcation API implies any binding? e.g an API or message
exchange such as XML etc?

Lines:		Page 2: 43 -
Comment:	Why 1, 5 is not included into the scope of the spec? I think all 4
interfaces are in the scope of the spec (Initiator <-> Coordinator,
Coordinator <-> Participant/sub-coordinator, Initiator<->Service and
Service<->Participant/Sub-coordinator). Specially if one does not make any
assumption on location of the actor and how a particular actor implemented,
it make sense to have a well defined interfaces between the actors which is
in the scope of BTP work.

Lines:		Page 3: 12 - 16
Comment:	Why is the demarcation API or the interface between the Initiator
and coordinator is out of scope?

Lines:		Page 3: 18
Comment:	Remove. I think the following paragraphs (excluding the first one)
are very relevant and should be part of the doc.

Lines:		Page 3: 20 - 23
Comment:	Remove, since these are not actors that are defined.

Lines:		Page 3: 36 - 37
Comment:	Remove this note (include it in a comment doc such as this)

Lines:		Page 3: 39 - 43
Comment:	I think we should have a section on Error and Recovery where we
should identify what errors can occurs and what recovery mechanisms we
should have. Logging?

Lines:		Page 4: 6 - 8
Comment:	Remove the remark on 2 phase locking...

Lines:		Page 4: 28 - 29
Comment:	I did not understand this paragraph... should we clarify the
interoperability?

Lines:		Page 4: 39 - 41
Comment:	Eliminate the indentation (typo ?)

Lines:		Page 5: 11 -14
Comment:	Remove.

Lines:		Page 6: 7 - 19
Comment:	We have not mentioned voting and re-voting until this paragraph.
If we are going to talk on re-voting we should define the voting first.

Lines:		Page 7: 5 - 9
Comment:	Remove.

Lines:		Page 8: 19 - 27
Comment:	I think the atomic units of work mentioned as least likely (group
including operations on different services) is most likely to be the
business transaction that will be coordinated by BTP. Atomic business
transaction that consists of several operations on a single service is
least likely to be coordinated by BTP, it is the Business Transactions that
is defined in ebXML BP.

Lines:		Page 8: 29 - 40 (Figure)
Comment:	Should be revised according to comment above (to include a atomic
group that includes operations with different services)

Lines:		Page 9: 33 - 38
Comment:	Under the light of above comment, is this example an example for
cohesion or atomic group? I think a better example would be if we put all
these three in a group and manage by BTP..

Lines:		Page 13: 14
Comment:	We need a section on Errors and Recovery. See BEA BTP submission.

Lines:		Page 13: 8 - 12
Comment:	This is the place we can add the result of our discussion on
transaction structure flags (that we have discussed on last weeks conf call)

Lines:		Page 13: 17
Comment:	We do not have an actor called Redirector. And what is BTM,
Business transaction manager and its role (compare to Coordinator)


Lines:		Page 13: 38 - 46
Comment:	Do you think this paragraph would be included into spec? Looks
like it is talking on format of address.

Lines:		Page 14: 1 - 4
Comment:	Move into the Error & recovery section

Lines:		15 - (Glossary)
Comment:	Remove some of the definitions that are not needed and ill-defined:
		1) Do we need to define Application? Do you mean BTP aware application?
		2) Contract ? What is this? Different than ebXML contracts? are we
defining one new here? Do we need this?
		3) Do we need these: Countereffect, Countereffect contract, effect,
inappropriate, ineffectual ?
		4) Is the definition of participant correct?
		5) Why a participant identifier needed? 
		6) Do we need a definition for transmission?