[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Your proposal for additional requirements is in essence what we did for
properties already. If there are no objections, I will add all of these
(including those you pose as questions) to the requirements doc. Your
comments regarding limitations of the chosen modeling language are
consistent with existing text in the requirements document which states:
"Where the data modeling language is not capable of specifying the
[attribute] constraint, the information model is required to provide
the most precise specification of attributes possible. Further, when
a specific mapping of the information model to a specific data model
is defined and the target data modeling language has a less robust
mechanism for expressing constraints, additional documentation
should accompany the data model to minimize confusion. If an
information model representation is not capable of expressing a new
kind of constraint, then this new constraint should be added to the
information model in a well-defined manner."
Again, if there is no objection, I will add a slightly modified version of
this text to the methods section.
> -----Original Message-----
> From: Joel M. Halpern [mailto:email@example.com]
> Sent: Wednesday, May 03, 2000 11:15 AM
> To: firstname.lastname@example.org
> Subject: Re: Methods
> Reading (and writing in) this discussion, I think we have
> agreement that we
> need methods.
> I have a guess as to what the question that is trying to be raised is.
> Given that we are defining requirements for the modeling language,
> what are the requirements on the language in terms of what it
> can say about
> I will list some of the information we probably want:
> Signature (types of operands and results
> Do we want formal or informal representation of error cases?
> Do we want formal or informal descriptions of valid ranges on the
> parameters and results?
> Do we want formal or informal description of valid combinations of
> parameters (if P1 is X, then P2 must be between Y and Z).
> Clearly, we would like to be able to capture some of this
> information. Equally clearly the more we require from the modeling
> language the harder it gets to meet the requirements.
> My personal take on this is to use whatever descriptive power
> I can get
> from the modeling language we select, but beyond a reasonable method
> signature I would not REQUIRE that the chosen modeling
> language have formal
> capabilities for other things.
> Once we have selected a modeling language, if it has additional
> capabilities, we will have to decide collectively how to use
> them. And for
> information we want to have that is not formally
> representable we will have
> to decide where we want that to live.
> Joel M. Halpern