*start*
01266 00024 US
Date: 2-Mar-82 11:07:45 PST (Tuesday)
From: Ayers.PA
Subject: What it Means to be an InterDoc-processing Editor
To: InterDoc
Reply-To: Ayers
Suppose you pass an InterDoc script to an editor&user and the user corrects a spelling mistake and returns the script.
Now you expect that "only" the spelling has been changed, and that the "other stuff" is still ok. And if the other stuff is damaged, you may claim that the editor is no really an InterDoc-compatible one.
Suppose somewhere in the incoming script we find
{ margin ← 5 ..... { margin ← margin + 5 .....
now if the editor changed that (without the user saying anything about margins) to
{ margin ← 5 ..... { margin ← 10 .....
we would probably claim damage. But what about
"margin ← margin + (3+2)" => "margin ← margin + 5" ?
or even
"margin ← margin + 5" => "margin ← margin + 5" ?
Butler did some good work on Interpress and the canonical representation et al. It doesn't seem directly applicable here because of the difficulties in enunciating what a "change" is -- how do I SAY that the user "changed the spelling but didn't fiddle with the margins" when I'm deliberately not saying ANYTHING about editing per se?
Thoughts appreciated.
Bob
*start*
01405 00024 US
Date: 2 March 1982 1:36 pm CST (Tuesday)
From: Johnston.DLOS
Subject: Re: What it Means to be an InterDoc-processing Editor
In-reply-to: Ayers.PA's message of 2-Mar-82 11:07:45 PST (Tuesday)
To: Ayers.PA
cc: Interdoc.pa
Starting with your last problem, a simple rule would be that in a non-string, the
number of spaces between "elements" has no effect. I think this rule is borne
out in most programming languages and seems to work fine and be
well-understood. Then modifying the number of spaces in the non-string
(TEXT$, etc.) portion of the script would be an effective no-op on the script,
which is what we are looking for.
As far as the first problem: in my opinion, since the rhs must be evaluated
completely before performing the binding, the results of "margin + (3+2)" and
"margin + 5" are the same since both result in adding 5 to the existing margin,
which was the desired result originally.
Given that a computer will be (at least mostly) performing the transcription, I
look ahead to implementations and don't think that your particular problems
would come up. However, I certainly expect to find that the same document
would be transcribed differently by two different editors (similar to a common
problem resulting in different programs from different programmers). Whether
this causes a problem is a significant question to be answered by this group.
Rick
*start*
00777 00024 US
Date: 2 March 1982 4:52 pm PST (Tuesday)
From: Horning.pa
Subject: Re: What it Means to be an InterDoc-processing Editor
In-reply-to: Your message of 2-Mar-82 11:07:45 PST (Tuesday)
To: Ayers
cc: Interdoc
Bob,
The position I have taken in the past (and will probably continue to hold, until
convinced otherwise) is that all operators in expressions represent structure. Space
between tokens is not, however, an operator.
To be specific about your examples,
{ margin ← 5 ... { margin ← margin + 5 ... => { margin ← 5 ... { margin ← 10 ...
margin ← margin + (3+2) => margin ← margin + 5
are both content-faithful, structure-losing transformations. However,
margin ← margin + 5 => margin ← margin + 5
is a full-fidelity regeneration.
Jim H.
*start*
00485 00024 US
Date: 3 March 1982 1:57 pm PST (Wednesday)
From: Mitchell.PA
Subject: Re: What it Means to be an InterDoc-processing Editor
In-reply-to: Your message of 2-Mar-82 11:07:45 PST (Tuesday)
To: Ayers
cc: Interdoc.pa
I am in full agreement with Jim Horning's answer about structure. I also expect
that we will have to define a canonical representation for a script (e.g., literals
combined with operators should be collapsed - "3+5" is "8" canonically).
Jim M.
*start*
01679 00024 USt
Date: 2-Mar-82 15:50:30 PST (Tuesday)
From: Ayers.PA
Subject: Encoding(s)
To: InterDoc
I'm tying to think about how an InterDoc script should be encoded (ie in bits) for transmission and storage. Here's some notes to get you thinking; feedback appreciated.
In "Full Interpress" Lampson/Sproull describe the "Interchagne Encoding" which uses only the graphical characters from ISO/ANSII to transmit the information. I quote:
The interchange encoding is designed to simplify creation, communication,
and interpretation of masters for the widest possible range of devices and
systems. For this reason, a master in the interchange encoding is represented
as a sequence of graphic (printable) characters taken from the ascii set ...
Communication of an Interpress master in the interchange encoding requires
only the ability to communicate a sequence of characters ...
Interpress then goes on to describe how to encode numbers, identifiers, strings, etc using those characters.
In InterDoc, an "interchange encoding" of this flavor would be quite beneficial; both for the Interpress reasons and also because one could then entertain the thought of an editor like Teco editing the raw InterDoc script.
BUT
There are also good reasons for a non character-oriented encoding. First, the character encoding is, in some cases, much less compact than a binary encoding would be. Second, a character encoding of the above form does not allow for NSString format. Third, a character-oriented encoding makes it hard (or very verbose) for an editor to insert what is basically binary data into (private) nodes or accelerators.
Comments?
Bob
*start*
00541 00024 USt
Date: 2-Mar-82 16:04:59 PST (Tuesday)
From: Karlton.PA
Subject: Re: Encoding(s)
In-reply-to: Ayers' message of 2-Mar-82 15:50:30 PST (Tuesday)
To: Ayers
cc: InterDoc
Bob,
I think the tack that InterDoc should take is the same one that was taken by Interpress: define the language in terms of the printable ASCII characters, but then announce an InterDoc-8x that is encoded. As long as there is a translation (service?) between legal InterDoc and legal InterDoc-8x, then we can claim victory and just press on.
PK
*start*
00210 00024 USt
Date: 2 March 1982 5:04 pm PST (Tuesday)
From: Horning.pa
Subject: Re: Encoding(s)
In-reply-to: Ayers' message of 2-Mar-82 15:50:30 PST (Tuesday)
To: Ayers
cc: InterDoc
I'm with Phil.
*start*
00568 00024 USt
Date: 3 March 1982 2:30 pm PST (Wednesday)
From: Mitchell.PA
Subject: Re: Encoding(s)
In-reply-to: Ayers' message of 2-Mar-82 15:50:30 PST (Tuesday)
To: Ayers
cc: InterDoc
Basically, I agree with Phil's position, but I may have a stronger dislike for the
Interpress-82 encoding than he does. When we finally have to deal with that
issue, I think it should be decided on a fairly rational basis. For example, both
the costs of storing (or communicating) scripts as well as the costs of
rendering/transcription need to be considered.
Jim M.
*start*
01427 00024 US
Date: 6 March 1982 11:26 am PST (Saturday)
From: Horning.pa
Subject: Yankee Group Comments
To: LaurelImp↑, Speech↑, Interdoc
Reply-To: Horning
The Yankee Group's comments aren't always accurate, but they're usually
interesting, and often cruel. Samples from their latest flyers for "The Report on
Electronic Mail" and a course on "The Next Generation of Local Networks."
The four electronic mail software packages singled out for discussion are
- Prime's OAS
- Digital's DECMAIL
- Wang's MAILWAY
- IBM's PROFS [printed in red]
The five Voice Store and Forward systems singled out for discussion are
- Delphi
- Xerox
- ECS
-Wang
-IBM
Q: I thought compatibility problems were a thing of the past?
Yankee: No way. Remember that we're talking about a diverse set of machines
attached to that local network electronic typewriters, personal computers, laser
printers. XEROX IS LEARNING THE HARD WAY ABOUT COMPATIBILITY
[emphasis theirs] its 820, 860, Star and Memorywriter all use different file
formats.
Q: So Ethernet's going to take over the world?
Yankee: Not so fast. Remember that the two leading OA vendors WANG AND
IBM, will never embrace Ethernet and two important future players will also go
their own way AT&T AND JAPAN, INC.
Q: What ever happened to WangNet?
Yankee: You mean "PaperNet". . . . The first "alpha test" of the network is
scheduled for first quarter, 1982.
*start*
03585 00024 US
Date: 28-Feb-82 19:40:26 PST (Sunday)
From: Ayers.pa
Subject: InterDoc Meeting Notes
To: InterDoc
Notes on the InterDoc meeting of 26 Feb 82
Present: Mitchell, Horning, Karlton, de LaBeaujardiere, Ayers, Reid, and Rick Johnston from dlos.
Topic: A Mitchell presentation of the base language.
Literals: booleans, strings, numbers, atoms=identifiers, NIL
defn: "Node" as a sequence of literals (marks) and "{ node }"s
defn: "Script" = "Document" as a "{ node }" -- possibly as modified by an InterDoc header. Note that there aren't any real semantics on scripts: "{ <Hi> }" is a perfectly good one.
defn: "Mark" as an identifier followed by a "$" Node can contain marks. [Editor's remark -- I'm presenting this in strict chronological order ..]
Semantic defn: Placement of marks within a node is not-interesting. All marks are just "attached" to the node they are in.
"The marks control the interpretation of the contents."
By the ordinary rules of parens, sub-nodes form a logical tree.
Pointing "across" the tree is done by "Links"
You declare a link by "identifier@!
Can then use it in any subnode of node declared in [notice: not
in node declared in]
There are two things [editor's remark: the names here are viewed
as being un-optimal] that use a declared node: the 'target'
"identifier!" and the 'source' "identifier@". Semantics:
the Link contains two sets: the set of targets and the set of
sources. "source" and "target" are interchangable EXCEPT we
define that Targets are only with a node (as marks) -- their
placement within the node's content is not material, while
'source's are placed within content.
Variables via identifiers: "name the variable, get its value"
[This is where the discussion got exciting. There are a number of ways to define a variable, and several ways to assign to it. The group wondered about this variety, and was sometimes confused by it. We agreed that we would appreciate examples. This is the discussion that we will pick up on at the next meeting.]
"Standard assignment" -- identifier := literal or other value
Declaration of variables. There are three areas of declaration: "the void" (where essentially undeclared things have been 'declared' by 'God') the "external" (the environment you get for free) and all the node levels in the tree.
In "the void", a variable has been given a value equal to its name. So reference to such a variable will return you an identifier.
Declaration: -- identifier: value. This declares one and gives it an initial value. The right-hand-side of this is evaluated BEFORE the declaration. Useful in re-defining a variable that exists in an outer scope -- you can say foo: foo+6.
"Strictly local binding" is doen with "←" Such a binding shields lower nodes from the outer values and prohibits re-defining: " foo ← 5 ....... foo := 6" is an error.
(We agreed that identifier names cannot carry semantics -- an implementation must not depend, e.g., on some set of variables all beginning with the characters "pq")
Equals declaration -- foo = 7 does a const; sub-nodes cannot define locals with that name. Useful for includes. [Brian suggested that we make "foo = 7 ...... foo = 8" an error but allow "foo = 7 ..... foo = 7" .. this met with approval.]
[...] syntax as a "record". Both record declaration and record component declarations can be of the various types. [This led into a complicated discussion that I do not reproduce.]
Meetings will be weekly at 9:45 on Friday's in 100G, Bayhill
Bob
*start*
00809 00024 US
Date: 9-Mar-82 15:27:23 PST (Tuesday)
From: deLaBeaujardiere.pa
Subject: Bravo to Star document conversion
To: StarUsers↑.es
Reply-To: deLaBeaujardiere.pa
Star version 22.3 will be able to translate correctly a number of bravo codes that were previously treated as "mystery characters" and rendered as black rectangles on the screen or zero-width characters on paper. The codes that are now correctly translated are:
ligatures ff, fi, fl, ffi, ffl: replaced by the corresponding 2 or 3 letters.
accented letters: corresponding letter in chset 40 if it exists, else unaccented letter.
inverted exclamation and question marks, minus sign: shown as they should.
em-dash, en-dash: replaced by en-dash.
em-quad, en-quad, figure space: replaced by non-breaking space.
Jean-Marie
*start*
00613 00024 USt
Date: 10-Mar-82 14:46:34 PST (Wednesday)
From: deLaBeaujardiere.pa
Subject: Interdoc character set
To: InterDoc
Reply-To: deLaBeaujardiere.pa
cc: deLaBeaujardiere.pa
"An Interdoc script is represented as a sequence of ASCII/ISO 646 characters". I interpret this to mean that the syntax part of the script is made up of these ISO characters but that the content of the document may include non-Roman characters like Chinese, Arabic, Greek, etc...
Similarly, the open-endedness" of the standard allows us to describe text flowing from right to left or top to bottom.
Right?
Jean-Marie
*start*
01709 00024 USt
Date: 10 March 1982 3:04 pm PST (Wednesday)
From: Mitchell.PA
Subject: Re: Interdoc character set
In-reply-to: Your message of 10-Mar-82 14:46:34 PST (Wednesday)
To: deLaBeaujardiere
cc: Mitchell
"An Interdoc script is represented as a sequence of ASCII/ISO 646 characters"
means that there are no characters anywhere in the script (viewed simply as a
sequence of characters) that are not ASCII/ISO 646 characters. Of course we must
be able to represent (code) non-Roman characters like Chinese, Arabic, Greek,
etc., but that, as we know, can be done using an alphabet as small as the binary
alphabet. In a recent message I pointed out that an Interdoc string constant of
the form <sequence of characters> is simply syntactic sugar for a node of the
form {$CHAR# c(s) c(e) c(q) ... c(t) c(e) c(r) c(s)} where c(char) denotes the
ASCII/ISO 646 numeric code for char. At this level, we could decide that the
sequence of numbers in a $CHAR node represent the NS character set codes.
Whatever is done there for non-Roman characters like Chinese, Arabic, Greek,
etc. can just be used by Interdoc unchanged.
Whether "text" flows from right to left or top to bottom (on some display device)
is specified, I assume, by attributes in the environment of the node in question.
The direction might be implicit if the node had a mark such as $CHINESE, or it
might have to be specified for something like ancient Phoenician or ancient
Hebrew where lines went alternately left to right and right to left (with the
characters on the right-to-left lines presented as the mirror images of the ones on
left-to-right lines so you could tell which way to read no matter where you
started!)
Jim M.
*start*
00986 00024 USt
Date: 10-Mar-82 15:08:06 PST (Wednesday)
From: Ayers.PA
Subject: Re: "An Interdoc script is represented as a sequence of ASCII/ISO 646 characters"
In-reply-to: Your message of 10-Mar-82 14:46:34 PST (Wednesday)
To: deLaBeaujardiere
cc: InterDoc
The meaning here is just as it is in the "Full Interpress" "Interchange Encoding".
The script itself is COMPOSED of those characters. I.e. each eight-bit successive value of the script, examined in binary, will prove to be one of those ISO bit representations.
A different question is "What can be REPRESENTED in the script?" Integers, for example, can be represented by spelling them out in decimal (say): "12345678" Characters can be represented by themselves (if they are fortuitously in ISO646) or by their Becker-sixteen-bit-value spelled in decimal, or by a variety of other techniques.
The original Sproull Interpress document discusses all this in good detail. You are welcome to borrow my copy.
Bob
*start*
01125 00024 USt
Date: 11-Mar-82 11:42:21 PST (Thursday)
From: Ayers.PA
Subject: On Quoted Values in InterDoc
To: InterDoc
Reply-To: Ayers
Maybe you already noticed this, maybe it's obvious, but I just figured it out.
The issue of "encodings" of InterDoc is tied to the interchange encoding and the language in a way that Interpress is not. Specifically, the "abbreviation" notion lets one assign a fragment of an InterDoc script to a variable as a quoted string. E.g. on page 16 of the Mitchell-Horning paper we find
PrintForm = '(TEXT$ <Data: > ... }'
This "obviously works" (you see an instant implementation) when the encoding is in fact ISO646. But it is not at all clear that it "works" if the encoding is different. Can I say
PrintFormBeginning = '{UNMATCHED$ <abbreviated node beginning>'
PrintFormEnd = '<and here is the end> }'
and then, further down in the script, say
... PrintFormBeginning < middle content > PrintFormEnd ... ??
As I read things, I can do that. Being able to store that incomplete language fragment into the variable seems to really hurt my implementation.
Bob
*start*
00962 00024 USt
Date: 11 March 1982 2:27 pm PST (Thursday)
From: Mitchell.PA
Subject: Re: On Quoted Values in InterDoc
In-reply-to: Your message of 11-Mar-82 11:42:21 PST (Thursday)
To: Ayers
cc: Mitchell
The thing on page 16 of the Mitchell-Horning paper is actually
PrintForm = '{TEXT$ <Data: > ... }'
which is a quoted expression containing a single value which is a node. You
can't do what you suggest with UNMATCHED$ because a quoted expression must
be a syntactically valid sequence of expressions. We explicitly avoided having
string substitution macros.
In another way you are right, however. Interdoc allows one to write expressions,
and expressions can denote structure. These expressions as forms, not just as
resultant values, must be retained in a script. Thus any private encoding must
be able to deal with them (of course, "compiling" the expression into some postfix
form as in JAM is an acceptable way of doing this).
Jim M
*start*
00350 00024 USt
Date: 11-Mar-82 16:44:09 PST (Thursday)
From: Ayers.PA
Subject: Re: On Quoted Values in InterDoc
In-reply-to: Your message of 11 March 1982 2:27 pm PST (Thursday)
To: Mitchell
Sorry 'bout that.
I looked at the bnf crosseyed or something. It clearly states the nice restrictions on the inside of the "'"s, as you point out.
*start*
01247 00024 USt
Date: 11-Mar-82 17:28:48 PST (Thursday)
From: Ayers.PA
Subject: InterDoc Syntax as Stack-Oriented
To: InterDoc
This is an attempt to look at InterDoc from an Interpress perspective. Jim and Jim, please excuse any injustices ...
Let us view the InterDoc language as being stack-oriented, and "interpret" it according to standard stack machine rules. Here's our script-fragment example:
{ 1.0 id1 ← 2 + 3 <content> }
making it look stack-oriented in its syntax, we might get
{ 1.0 2 3 + id1 ← <content> }
Let's consider how that might be "executed":
1. The "{" marks the stack.
2. Successive items are pushed on to the stack, with operators doing
the appropriate pops. The "←" operator takes two arguments.
3. When we get to the "}", the stack (above the mark) contains
1.0 <content> -- exactly the "content" of the node. The "}" thus
processes the content.
Is there anything wrong / heretical / injust about looking at things as above? Should we consider making the syntax stack-oriented a la Interpress?
Bob
PS: I note that the stack-oriented syntax has the (possible) disadvantage that it may be harder to notice which ids are part of the node's content and which are "consumed" by operators.
*start*
01031 00024 USt
Date: 11-Mar-82 19:03:32 PST (Thursday)
From: Ayers.PA
Subject: InterDoc Meeting at 9:30 Bayhill 100G Friday
To: InterDoc
Reply-To: Ayers
Here is a summary of the meeting of last friday.
There was a discussion (continued from the previous meeting) of declaration and assignment. Things appeared to be clarified by Jim Mitchell's presentation of the true semantics of the situation. Since Jim has mailed the semantic equations, I propose to not interject my notes.
Brian Reid expressed worry about the (direct) editability of InterDoc scripts. [Editor's aside: I'm beginning to be concerned about page-level access to remote InterDoc scripts .. can Star, for example, parse only n% of the script to show the user the first page?]
Jim Horning expressed worry about the "abandonment" of the "interchange" encoding standard a la Interpress 82. This sparked a discussion, and we agreed that an encoding which can be pipelined (little context-sensitive) to and from the "interchange" encoding is ok.
Bob
*start*
01472 00024 USt
Date: 12 March 1982 9:04 am CST (Friday)
From: Johnston.DLOS
Subject: Re: InterDoc Syntax as Stack-Oriented
In-reply-to: Ayers.PA's message of 11-Mar-82 17:28:48 PST (Thursday)
To: Ayers.PA
cc: InterDoc.PA
I have one big problem with a hard-to-understand "language," and that is that
the need for it must be deemed that much greater if it is to be accepted, if it is
more complex than really required. (I'm trying to say, "if it's too hard to use, we
may be doing all this work for northing since nobody will adopt it.") I find the
original proposed representation relatively easy to understand. I say this, even
being one of the group which feels that algebraic notation on calculators is
terrible, and RPN is beautiful. When writing something down, stack-orientation,
or reverse, or postfix, is harder to understand. This causes it to be harder to be
sure you are writing it (or writing the program that will write it) correctly, and
makes it harder to read and understand (which some programmer will have to do
during development). Although it would perhaps be simpler, in a strict sense, to
implement, I feel the disadvantages outweigh the advantages.
Although I don't have any experience with Interpress, I have looked at some of
the programs one of the guys here is writing in Forth. He understands it fairly
well, and he still has occasional trouble putting everything in the right place.
I vote we don't go stack-oriented.
Rick
*start*
00491 00024 USt
Date: 12 March 1982 8:55 am PST (Friday)
From: Mitchell.PA
Subject: Re: InterDoc Syntax as Stack-Oriented
In-reply-to: Ayers' message of 11-Mar-82 17:28:48 PST (Thursday)
To: Ayers
cc: InterDoc
Yes, we could use a stack-oriented syntax. Jim and I looked at the issue very
briefly and decided that we were not really wedded to any specific syntax and
that we could treat syntax as the sugaring on the semantic cake once it was
fully, rather than half-baked.
Jim M.
*start*
00893 00024 USt
Date: 12 March 1982 9:03 am PST (Friday)
From: Mitchell.PA
Subject: Re: InterDoc Meeting at 9:30 Bayhill 100G Friday
In-reply-to: Your message of 11-Mar-82 19:03:32 PST (Thursday)
To: Ayers
cc: Mitchell
Re: [Editor's aside: I'm beginning to be concerned about page-level access to
remote InterDoc scripts .. can Star, for example, parse only n% of the script to
show the user the first page?]
At the moment I take the stand that one must completely render an Interdoc
script into editor *'s internal format before editing the document it represents.
Perhaps when we understand things better we should revisit this, but counter
examples spring readily to mind: e.g., there is a reference (source link) at the
beginning of the document whose target is at the other end, or the last item of
the root node is a mark (probably a bad idea and worth discussing).
Jim M.
*start*
01467 00024 USt
Date: 10-Mar-82 10:33:29 PST (Wednesday)
From: Ayers.PA
Subject: "Presentation" Attributes ??
To: InterDoc
Reply-To: Ayers
I suggest that there is a set of attributes that control the page-formatting of a document; that this set is definable and separable; and that we need to define some members of it but leave the set "open ended."
Within these "presentation attributes" I include all our traditional page formatting information: headers, footings, page numberings, columns, etc.
And I include our traditional paragraph formatting information: indenting, leading, first-line leading, etc.
I claim that we need to separate this set out because we need to leave it open ended; by stating that the attributes in the set (known or not) are all "presentation" attributes, we let a renderer ignore the attributes that he doesn't understand with only an "appearance warning" to the user.
I claim that we need to leave the set open-ended because there are too many ways to present paragraphs and pages. Trying to define "everything" will produce infinite work -- just consider the paragraph possibilities -- Jean-Marie just mentioned the "big initial letter that the rest of the text flows around" paragraph format.
Query one: what about these claims?
Query two: how do we establish a "set" of attributes so that an "unknown" attribute can at least be recognized as a member of the set? [A record does not seem appropriate somehow.]
Bob
*start*
01432 00024 USt
Date: 12 March 1982 9:37 am PST (Friday)
From: Mitchell.PA
Subject: Re: "Presentation" Attributes ??
In-reply-to: Your message of 10-Mar-82 10:33:29 PST (Wednesday)
To: Ayers
cc: Mitchell
Claim: the only way to associate any set of meaningful attributes with a node is
to place a mark on that node for which that attribute set is a "relevant set of
attributes." Typically, your presentation attributes would be associated with the
root node of a document using a mark such as PAGINATED$, but of course any
node could carry such a mark.
Your presentation attributes, while being open-ended are actually bound with
respect to a given mark. Many marks having to do with formatting may,
however use common attributes such as margins, so it behooves us to try and get
those right individually, but we don't have to identify a class such as
presentation attributes and then worry about how to leave it open-ended because
the point is moot. What we do have to do is get the set of attributes relevant to
a given mark right, and we have to spend some time defining attributes that
might be relevant to a number of marks in a way that accommodates them
reasonably. These are easier tasks (not easy just easier) than what you propose.
I also think that the problem in your Query 2 has the same answer: you
recognize an attribute as a member of a set because it is relevant to a mark
carried by a node.
Jim M.
*start*
02021 00024 USt
Date: 30 March 1982 2:44 pm PST (Tuesday)
From: Horning.pa
Subject: "Electronic information interchange in an office environment"
To: Interdoc
[Somebody put in my box a copy of an article by M.R. DeSousa in IBM Sys. J.,
Vol. 20, no. 1 (1981).
I think he understands the problem better than the solution. Some of his goal
statements sound pretty reasonable in isolation. We might want to quote or
paraphrase them in some of our motivational material.]
. . . Irrespective of the configuration, the system must be easy to use if it is to be
effective. The complexities of interfaces and data forms must be transparent to
the users. To expect a sender of information to know the device and data-form
requirements is unrealistic. The sender should be able to request that the
information be distributed and shold not have to be concerned about the devices
used by recipients. . . .
An enter and edit data stream should also be portable between differing devices
of unlike functional levels. For example, if information is entered on device A
and sent to device B for additional entry and editing, device B should perform
identically those functions that both devices support and must recognize those
functions it does not support and provide a responsible, appropriate response. . .
Interchange is defined as the proper interpretation of the data stream, but not
necessarily complete execution of the function implied or expressed. . . .
Subsequent editing may then be used to produce a document that may be
processed on either the originating or the receiving system.
The means to accomplishing interchange is defined by an architecture that
enforces a standard definition of syntax and semantics for reformattable, editable
text. The architecture specifies a data stream organization that . . . provides
sufficient structure and redundancy in the data stream to support nonsequential
access whhile allowing for identical interpretation whether processed sequentially
or nonsequentially. . . .
*start*
00980 00024 USt
Date: 30 March 1982 3:14 pm PST (Tuesday)
From: Horning.pa
Subject: Re: "Presentation" Attributes ??
In-reply-to: Your message of 10-Mar-82 10:33:29 PST (Wednesday)
To: Ayers
cc: Interdoc
Bob,
Having just sorted 500 messages that arrived in my absence, let me comment on
this one. Sorry if the matter has been settled in the meantime.
It is not obvious to me why page-formatting and paragraph-formatting attributes
belong in the same set, except that you might want both to be open-ended.
When a paragraph crosses a page boundary, from which page does it take the
formatting information--or does that change at the boundary? Might different
editors take different positions on this?
Should it be obvious to me why a record/environment isn't a good way to collect
and isolate an open-ended collection of related attributes? That was one of the
principal motivations for introducing them; if they're not good for that, maybe
we should fix them.
Jim H.
*start*
00656 00024 USt
Date: 30 March 1982 3:19 pm PST (Tuesday)
From: Horning.pa
Subject: Re: On Quoted Values in InterDoc
In-reply-to: Your message of 11-Mar-82 11:42:21 PST (Thursday)
To: Ayers
cc: Interdoc
Bob,
Page 13 of "Towards an Interchange Standard . . ." agrees with my recollection
that we had decided to prohibit unbalanced brackets in abbreviations (despite the
charms you evoke): "One can also bind a sequence of unevaluated expressions to
an identifier. . . ." The syntax does not allow unbalanced brackets in expressions.
You worry about the implementation, I about the meaning, of the construct. But
we agree that it is bad.
Jim H.
*start*
00815 00024 USt
Date: 30 March 1982 3:24 pm PST (Tuesday)
From: Horning.pa
Subject: Re: InterDoc Syntax as Stack-Oriented
In-reply-to: Ayers' message of 11-Mar-82 17:28:48 PST (Thursday)
To: Ayers
cc: Interdoc
Bob,
Heretical? No.
Clearer? Opinions may differ.
Easier to implement? Not so's you'd notice.
I prefer to think about examples using the infix notation. Polish MAY be a more
compact encoding of what I would think of as the same abstract language.
However, it's not clear to me that it wins very much in Interpress, because of
the number of operators that require an extra operand to specify the number of
other operands. Brackets aren't very space-consuming, and have the advantage
of being pretty readable, and providing some redundancy for recovery/diagnosis
if things get confused.
Jim H.
*start*
01264 00024 USt
Date: 30 March 1982 3:35 pm PST (Tuesday)
From: Horning.pa
Subject: Re: InterDoc
In-reply-to: gcurry.es's message of 12-Mar-82 14:04:03 PST (Friday)
To: GCurry.es
cc: Interdoc
"This is a recap of the three points I made during the meeting; any of the three
is arguable.
Assertion #1. It is desirable for Interdoc to be able to encode behavior/editing
rules.
Assertion #2. Reasonable editing rules exist which modify content as a function
of PRESENTATION (e.g., hyphenation, when hyphen is seen as a character
rather than a presentation artifact). The set of such rules is open ended.
Assertion #3. Interdoc has no way of representing such rules except by naming
them and enumerating the names in the standard."
Gael,
I accept assertions 2&3. The inferences that you draw from the combined set
reinforce my disagreement with assertion 1.
It is fine for Interdoc to associate a named attribute with a part of a document.
The interpretation of that name as a behavior specified by an arbitrary program
is not something that I am eager to try to standardize. However, if and when
agreement on such a standard is reached, nothing in layers 0, 1, and 2 of the
standard should preclude a section of layer 3 that specifies it.
Jim H.