[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Status update
> One of the legitimate concerns you raise is: How far do we want to go? One
> alternative is to only define a graphical description with accompanying
> textual definitions of the attributes and methods. On the other extreme,
> another alternative is to actually use or specify a language that
> describes the attribute and method relationships with enough detail that a
> mechanical means for mapping those structures to specific protocols could
> be supported.
[Dan] I think that we need to reach agreement that the later
broader scope is what we want to achieve. IMO this would be the real value
that this work could bring, and without trying to reach it, we might just
engage in another beautiful academic exercise. Is it too broad?, is it too
early?, is it not achievable? better know it now...
> The debates about the various requirements that occurred over the course
> of the past few months were an attempt to solidify those requirements that
> people felt needed to be included in order to meet the above stated goal.
> During these discussions, some lack of clarity in the goals surfaced and
> this has hopefully been addressed in this latest version of the
> requirements document. In turn this convergence on the requirements also
> implied a course of action which did not suggest that we only focus on a
> graphical respresentation. Rather, the focus on the various requirements
> suggested a strong interest in specifying or using some type of modeling
> or data definition language.
> There was also very clear concensus around the desirability of using OO
> concepts including inheritence, associations, and methods to solve the
> problem stated above. I would specifically agree that not all the issues
> were fleshed out. This was the main reason for some parallel work taking
> place to propose guidelines for the use of these various constructs.
> As to the question of languages, if these other issues have been addressed
> in sufficient detail, then we should begin discussing how we can solve
> this problem. In other words, what language provides the best fit for our
> needs as represented in the requirements doc. That said, if there are
> folks who would like to have another round of discussions on the various
> requirements, that is an obvious precursor to opening any discussion on
> language alternatives. Naturally, a more detailed discussion of the goals
> is also a precursor. Therefore, if there are any clarifications,
> refinements, or details that folks would like to raise with respect to
> these goals, these comments would be most welcome.
[Dan] goals definition precedes requirements... requirements
precede language definition ... In large projects like this, some concurrent
activities may happen, but a common understanding of the main goals for all
participants is mandatory. Do we agree that we aim to 'use or specify a
language that describes the attribute and method relationships with enough
detail that a mechanical means for mapping those structures to specific
protocols could be supported'.