specs
RE01 Rice Brian T. EM2
BRice@vinson.navy.mil
Fri, 1 Jan 1999 19:38:42 +0300
> Bad definition of object. Whatever they are should be defined by
> their properties, not by their implementation details (bytes???).
>
it's not the definition, it's merely a way of saying "what it is" in a
paradigm like the C language's, to allow some implementation starting
points.
> Hyperlink search problem?
>
the ability to find all references or even a specific reference to an arrow
or object at hand. in a several megabyte image file, this could be quite an
overhead or bottleneck in terms of interactivity.
> Quite likely. That needs some clarificationtion.
> Clear definition of the grouping mechanism, but it's all tangled in
> the rest of the paragraph.
> No purpose specified for the grouping mechanism.
>
ok. i can see why you're confused. what the grouping construct is good for
is merely syntactical orthogonalization of all meaning. its therefore a
completely general-purpose mechanism for isolating meaning and mechanism. i
can use it to make statements about anything, by describing a mapping, a
literal syntax structure in a language, or a database.
what i'm saying about arrow-creation is that it will always be contained
within some context, just as a message from the user to "delete all" should
never nullify the system, because the system already is limiting the user to
some context in order to ease interface problems.
> It's getting there, but still way to general yet.
> And it is far from complete.
>
ok.
> An simple example:
> At work we are given descriptions of output files that need to be
> created from our database. We are told the record size.
> The starting and ending position of each field.
> The way data should be represented in each field.
> A description of what data should be placed in each field.
>
i'm not sure how this relates to this case. could you explain in a more
explicit way?
> For your arrow language, we need.
> A precise specification of exactly what is your arrow language.
> A description of what each of the operators does, and some description
> as to why you picked what you did.
> A description of how the arrow language can be used to make a complete
> system.
> No implementation details except as hints.
>
most of it is just syntax. semantics would derive from the system of arrows
made by the user itself.
i will, though, walk through the ideas for operators in more definite terms
and give examples in a little while.
> I expect this to be a least a several page document, that will take
> a little while to write.
> The specifications documents be what the talk between
> Rice, Tril, and Fare are mostly about.
>
right. i'll try to fulfill you're requirements there.
> This should break tunes down into 2 hard problems (implementation, and
> specification) instead of 1 monster, problem.
>
yes. i would like that too, as long as i can trust you all to implement it.