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.