OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Requirements


 The phone conference is coming soon, so I send my latest mail before the phone conference directly to this list.

 I would summarize the situation about the requirements document:

1. We have 4 more weeks left until the initial deadline for the requirements document. It means one or maybe two phone conferences until the f2f. It means we have a very limited time for making real decisions. So we should speed up the work if we are decided to keep the deadline. 
Therefore either we have to decide on the acceptance process of the requirements (vote) and make a progress plan how can we fit into this deadline, or we should extend the deadline.

2. There were 3 different opinions on the last phone conference about how to proceed with the requirements document. Nokia proposed an early draft to start with, but a different idea was brought up during the conference to start our from the WS-Reliability draft as it already contains requirements. There was no loud obligation so we chose this method.

3. I personally had difficulties with identifying the requirements of the WS-Reliability draft. It does not contain explicit requirements, although some basic functional requirements can be deducted from the document. 
 I don't know about any other progress on collecting the initial requirements.

4. Therefore I made up the attached document containing very basic requirements covering the functionality of the WS-Reliability paper, what I think are not questioned considering the comments to the mailing list until now. This draft contains only 8 requirement points. I propose to vote about these points either as a whole or point-by-point. Remember, we have only 4 weeks left. 
There were debates about the file format, but I think this discussion should not set back the progress of the content. Rigth now I send it in PDF format.


5. In order to speed up the progress I would propose the following process:

 - Let's decide what is the meaning of the requirements draft. I can imagine two possibilities:
    a) -- What the requirements draft contains is accepted by the TC. Either because there as no obligation to the requirement points or there was a vote about it.
    b) -- It is a working document, and it contains proposals. (Why should the issue list be separated in this case?)
I propose to have a vote if there is no consensus.

- Let's vote about the document I've sent in this mail. I think these are the basic functional requirements. I hope at least one point can be accepted, then we have an initial version of the document.

- All official requirements proposal sent to the mailing list should be classified as a requirement issue.
   -- if version a) is accepted, then they should be put on the issue list and the process must be clarified how the decision will be made when the discussion is finished and who can call for a vote.
   -- if version b) is selected, then all proposals can be put into the requirements draft directly, and can be removed if the decision is made. Decision process must be clarified here as well.

6. Although it may be an interesting theoretical question what requirements can be "reverse-engineered" from the WS-Realibility paper, but it looks to be slow and disputable to solve, as there are no explicit requirements in that document. As we are running out of time, I propose to use the process in point 5 if anything - that in someone's opinion can be deduceted from the WS-Reliability paper - is missing from the actual version of the draft. It could lead to equivalently good result both in case a) or b) above, but we don't have to waste more time on the initial step.

I am looking forward to talk with you soon.

	Best regards,


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]