Hi Thilo, Quoting [Thilo Kielmann] (Apr 27 2006):

Hi group,

currently I am trying to distill a concise set of requirements from the requirements doc (draft) into the introduction of the API spec...

What puzzles me is the terminology used in the requirements document. (And here I am referring solely to the bullet points with actual requirements.)

We have 1 x "must be supported" a lot of times "should be supported" and "...messages on top of streaming... should be CONSIDERED..." and many versions of saying that something should NOT be considered...

This all does not really match what the (strawman) API includes and excludes.

True. This showes the need of the req-document. The strawman is quit off-target in some respect. OTOH, there are reasons why we started with the strawman scope as we have it now. We should explain these reasons in the spec intro.

I am afraid we need to get the requirements doc straight first...

Ah, I think not. Wording might need fixing, agree - but I think that the fact that the API is off target in respect to the requirements needs fixing in the API, not in the requirements...

Do we need to refer to the (un)famous RFC that explains the meaning of "must" and "should" etc. to make the requirements stricter???

That would probably be a good idea... Cheers, Andre.

I am pretty sure this is all just a 'presentation' issue, but currently things are pretty fuzzy to me.

Any good suggestion?

Thilo -- "So much time, so little to do..." -- Garfield