*start*
10613 00099 US 
gvMsgID: Horning.pa $ 3#203@ 6-Jan-83 12:11:20 PST
Categories: InterScript
Date:  6-Jan-83 12:10:21 PST
From: Horning.pa
Subject: Programming Research section of Activity Report
To: Schmidt
cc: Horning, Levin, GNelson, Mitchell, Rovner, TonyWest, Sturgis, Atkinson, Lampson

IV.	PROGRAMMING RESEARCH

A.	Cedar

The Cedar project is a collaborative effort between CSL and ISL intended to provide a new programming environment based upon D-machines. It involves language design and implementation; a comprehensive suite of integrated packages for graphics, screen management, input/output, and text manipulation; user-extendable executive and debugging facilities based on an abstract machine model; and facilities for managing multiple versions of large software components. Cedar runs on top of the Pilot operating system on the Dorado, Dolphin and Dandelion processors. Although Dolphins and Dandelions are considerably slower than Dorados, many applications written in Cedar perform adequately on all three machines. Cedar is currently being used by most computer professionals in CSL and ISL for their daily work. Development continues on various experimental prototypes such as a calendar system, a mail system, three-dimensional graphics applications, color graphics applications, an experimental system for organizing information spatially, and several distributed applications based on a "remote procedure call" facility. The released system involves over 500,000 lines of source program and 2700 files and is still under intensive development; there were seven releases during the last six months.

The Cedar project has four levels of activity:	

* the core, which consists of the microcode, operating system, and language.	

* fundamental tools, which include the editor, debugger, and executive, all using a common display interface. The editor and display interface were developed by ISL.

* packages, notably the data base, mail, printing and graphics packages. Reports on these appear in other sections.	

* documentation.


Activities

Major improvements to the Cedar system have been made in the past six months. 	

Core:

In order to enable Cedar to run efficiently on Dandelions, both new microcode and a new, replacement central processor were implemented. The Mesa/Pilot microcode uses almost the full 4K words of the standard control store. Cedar requires additional microcode to implement Floating Point instructions and Garbage Collection instructions. Fourteen Floating Point op-codes were implemented, comprising about 600 lines of Dandelion microcode. The resulting Cedar performance on Dandelions is now about the same as on Dolphins. We expect additional improvement, perhaps another 30%, with the addition of the remaining Cedar op-codes. The new central processor's control store is implemented with 4K by 4 bit IC's, which allows control memory to be inserted in banks of 4K words up to the maximum of 16K.

The use of collectible storage has been pushed lower in the system to support a new loader based on interface records and to enable conversion of the software associated with system initialization from Mesa to Cedar.

The abstract machine has been extended to deal with breakpoints, processes, and the component programs and interfaces of a running Cedar system, and to support world-swap and tele-debugging. Clients of the abstract machine, notably BugBane and the executive, are written largely independent of the locality of the world in which symbolic expressions are evaluated. Use of CIFS has been thoroughly integrated with the abstract machine; all symbol and source files associated with a released system are accessible to the debugger, whether or not copies reside on the local disk.

The interface design for a new file system for a Cedar workstation was completed. It provides the normal file system facilities for opening, locking, and manipulating files. It also provides several unusual features: an automatically managed cache of remote files; a transportable, backed-up, private file name space for each user; facilities for binding private names to shared, remote files; facilities for finding the version of a remote file that was created at a particular time.

Research in software development tools, notably the DF files system and the System Modeller, were described in Schmidt's Ph.D. thesis and in a paper on "Practical use of a polymorphic applicative language," which was accepted for the ACM Conference on Principles of Programming Languages. The DF files system is now being used by Xerox OSD/SDD for software version management.

[R. Atkinson, A. Birrell, R. Levin, J. Maxwell, P. Rovner, E. Satterthwaite, E. Schmidt, M. Schroeder, L. Stewart, H. Sturgis, E. Taft]	

Fundamental Tools:

The interfaces between BugBane and the Executive were overhauled and the implementations unified, yielding major improvements in the smoothness and robustness of the system. BugBane was simplified to use the abstract machine implementation exclusively for access to symbols and system data structures. The Executive was extended to incorporate a separate "action area" for each pending "action" (breakpoint, uncaught signal, etc.). Work has begun on implementing various experimental "creature comforts" for Cedar such as automatically generating and updating change logs when the user edits a file. Some of these are already in limited use.

Most Cedar users employ BugBane for their debugging; world-swap debugging is used primarily by developers of the lower-levels of the system. Several alpha-testers are using Cedar rather than CoPilot for world-swap and tele-debugging.

A high performance, general purpose window package and user environment has been largely completed. The release of Tioga 1.0 marks the completion of a reliable, high quality editor and page formatter which is now in general use by the Cedar community in ISL and CSL. 

[R. Atkinson, P. Rovner, S. McGregor (ISL), W. Paxton (ISL), M. Plass (ISL), W. Teitelman]	

Package catalog:

The package catalog includes, among other things, entries for Graphics, Data Bases, Performance Measurement, Screen Management, Lists, Priority Queues, Symbol Tables, Mail, Calendar, Reminder, Remote Procedure Calls, Communication, Random Numbers, File Comparison, Graph Data Plotting.  [J. Horning]	

Documentation:

The first version of the Cedar language reference manual was released. About 80
pages long, it contains
	a complete grammar for the language;
	a formal definition of its semantics by a set of rewrite rules which convert a Cedar program into a program in a closely related but much simpler Kernel language;
	a set of examples;
	English text which explains the semantics and clarifies subtle points of syntax;
	a tabulation of all the built-in types and type constructors, and all the built-in operations of the language;
	English text which gives the semantics of the built-in types.
Part of the manual is a one-page grammar for the full language, a shorter grammar for the safe subset, and a two-page summary of the grammar, semantics and examples. Still to come is a formal definition and informal explanation of the Kernel language.

The rest of the Cedar Manual nearly doubled in length (to almost 300 pages), and now contains manuals for most of the major subsystems and packages. A version consistent with the 3.5.2 release of the software was printed for general use. [M. Brown, J. Horning, B. Lampson, S. McGregor(ISL), J. Mitchell, W. Paxton(ISL), W. Teitelman]	

Plans

The new file system will be implemented and integrated into the Cedar core to replace both CIFS and the "common software" directory system. More of the software associated with system initialization will be converted to use Cedar features, notably collectible storage, ROPEs and IO. The remaining Cedar opcodes will be implemented in microcode for the Dandelion. Use of CoPilot will be entirely replaced with use of Cedar for both world-swap and tele-debugging. To facilitate changes to object file formats (BCD's, symbol tables) and basic system data structures, the abstract machine implementation will be extended to support cross-debugging. The architectural changes associated with the Trinity and Klamath releases of Pilot will be incorporated into Cedar. Improvements will be made to the operating system's management of virtual memory and files. The implementation of the System Modeller will be completed and integrated into the standard system. This should end the major Cedar development effort, leaving several related, but smaller, follow-on projects. With the arrival of more D-machines, virtually everyone in CSL and ISL will convert to Cedar.

B.	Programming Methodology

Program Verification: We continued theoretical studies of the verification problem for large systems, working in the framework of the calculus of weakest preconditions. We found weakest precondition equations for procedure calls and "exception-handling" that are suitable for use in mechanical verification. We have found an attractive axiomatization for a reachability predicate for linear lists. [G. Nelson]

Specification Techniques: We continued our investigation of the utility and limits of the ``algebraic'' approach to specification when applied to real system problems. We helped the Larch project at MIT to develop a family of formal specification languages. We produced an informal introduction, a reference manual, and a handbook of examples for the Larch Shared Language. [J. Horning, J. Guttag (MIT), J. Wing (MIT), and J. Zachary (MIT)]

Abstract Kernel: Work continued on a generalization and abstraction of the essence of Cedar, without worrying about compatibility with the current implementation. We constructed a precise semantics for this language, based on Plotkin's inference-rule operational semantics. Its distinguishing features are the treatment of types, bindings and declarations as first-class values. [B. Lampson and R. Burstall (U. Edinburgh)]

InterScript: We continued the development of a standard for the interchange of editable documents, in collaboration with a standards committee formed in OSBU/SDD. A revised version of the report "Towards a Standard for the Interchange of Editable Documents" was produced, and an initial draft of document standards was produced by R. Ayers of SDD. In December, a PARC Forum on InterScript was presented to acquaint others with the status and scope of the effort. [J. Mitchell, J. Horning, S. McGregor (ISL), R. Ayers (OSBU), G. Curry (OSBU), J.-M. deLaBeaujardiere (OSBU), P. Karlton (OSBU), J. Stepak (OSBU)]	

*start*
05154 00098 US 
gvMsgID: GCurry.ES $ 65#63@ 6-Jan-83 12:26:08 PST
Categories: InterScript
Date:  6-Jan-83 12:26:24 PST (Thursday)
From: GCurry.ES
Subject: Interscript in an Ethernet Environment
To: InterScript.pa
cc: Lauer.pa

Hugh's message below wonders about the proper relationship of Interscript (especially internalization and externalization times) to a "model" editor.  With the exception of staging questions, and differences in speeds of externalization and internalization, the considerations seem the same for Star and Tioga.  The considerations seem to have more to do with network citizenship than Star-ness.

What kind of convention does Tioga make.  Wouldn't it be wise for Star and Tioga to take the same approach?

Gael 

------------------------------
Date:  6-Jan-83  9:47:25 PST (Thursday)
From: Lauer.pa
Subject: Interscript in OS 5.0 Star
To: StarArchInterest^.es
Reply-To: Lauer

I would like to try to articulate a strategy for Interscript implementation and its relationship to the next release of Star.  This would be both a subject for discussion and a constraint that the Star redesign would have to consider.  This message is an attempt to explain my thoughts and to provoke discussion.  Within several months, we (OSD) will have to decide whether or not to commit to the Interscript concept and structure our development accordingly.  (because fo the fundamental nature of this issue, it is not reasonable to postpone a decision until next year.)

Interscript should be the lingua franca of editable documents on the network.  First class citizens of the network should both speak and understand Interscript as a matter of preference.  Citizens of the network who don't understand Interscript are, by definition, second class.  While the network facilities will always permit non-Interscript communities to communicate among themselves, members of such communities cannot expect the rest of the world to necessarily speak their languages.  Instead, they have to appeal to conversion services which knows how to translate between Interscript and their languages.

In general, SDD's strategy should be to NOT provide automatic conversion of document formats to and from Interscript in the basic services of the network.  In particular, the mail service should NOT be required to determine what sort of client it has, then locate and invoke an appropriate conversion service to satisfy the needs of that client.  Instead, it is the client systems responsibility to cause the conversion to happen when needed.  Whether or not this is visible to the user is a matter of the design of the individual clients systems.  Very primitive clients may force their users to explicitly mail documents to conversion services; but better implementations should provide automatic or semi-automatic conversion, either within the same system element or by invoking a service.

Star should be the model first-class citizen.  It should speak Interscript as a matter of preference in all documents stored or mailed externally.  That is, Interscript should be, as a matter of policy, the external document format of Star.  Star workstations should communicate with each other in Interscript, not the internal format (if that be different).

From the practical point of view, it is unlikely that the next release of Star can fully implement Interscript or that the Interscript standard will have evolved to the point where it can fully describe a Star document.  This is okay.  It is reasonable that the introduction of Interscript be evolutionary, starting with, say, the main body of text of a document and gradually expanding in later releases to include graphics, equations, and other facilities included in Star documents.  In any particular version, the non-conforming parts of a document might be in a private format and hidden by legal Interscript escape sequences.  HOWEVER, the Interscript architecture and strategy must be included in the redesigned Star from the beginning.

Given this strategy, there are a number of issues that must be discussed and resolved:

1.	Should the internal and external document formats of Star be different? or is it reasonable that Star can directly manipulate an Interscript document?  [My intuition is that internal and external document formats ARE different.  This is based on observations of Bravo and other editing subsystems around here.]

2.	Assuming that internal and external formats are different, when should the conversion be done?  Some possibilities are:

		at the time the document is opened or closed (makes open very
		slow)
		
		at the time the document is prepared for editing (e.g., when the
		user presses the 'edit' button and again when he 'saves')
		
		when the document is transmitted onto the network or to a floppy
		(but this means looking inside of each folder and doing
		conversion on the fly)
		
		others?

3.	How should the Interscript project be managed and maintained, once the basic structure and specification are defined by the current effort?
		
		
		
Comments? other issues? 

/Hugh
		
		


----------------------------------------------------------------
*start*
01708 00099 US 
gvMsgID: Horning.pa $ 3#203@ 6-Jan-83 13:51:10 PST
Categories: InterScript
Date:  6-Jan-83 13:50:11 PST
From: Horning.pa
Subject: Re: Interscript in an Ethernet Environment
In-reply-to: GCurry.es's message of 6-Jan-83 12:26:24 PST (Thursday)
To: GCurry.es
cc: InterScript.pa, Lauer.pa

Gael,

I agree that "the considerations seem to have more to do with network citizenship than Star-ness." Let us hope that Star leads the way in network citizenship, however.

I find myself in considerable sympathy with most of the sentiments that Hugh expresses. My opinion on the issues that he raises at the end are:

1. I'm not sure exactly which "internal" format is being discussed here. There must surely be some differences between the in-memory format used for editing and Interscript (e.g., efficiency will demand representing trees with pointers, rather than nested brackets). I can see arguments for making Star's (local) file format correspond to either the in-memory format or to Interscript; it would be hard to justify using yet a third format, however.

2. In Dealer yesterday, Bill Paxton outlined the Tioga II strategy for conversion between file and in-memory formats, in which opening a document forces (inward) conversion only for nodes that appear on the screen, and allows conversion of other nodes to proceed in background. By associating an "edited" bit with each node, (outward) conversion on a save is needed only for nodes that have changed. It would seem that a similar strategy might well be attractive for Star.

3. Interscript maintenance should be the primary responsibility of a single person, who consults with a larger advisory board on major issues.

Jim H.
 
*start*
00477 00098 US 
gvMsgID: Murphy.PA $ 48#26@ 7-Jan-83 11:51:34 PST
Categories: InterScript
Date: 7 Jan. 1983 11:52 am PST (Friday)
From: Murphy.PA
Subject: Request for Paper
To: Mitchell
cc: Murphy

Jim -

Jerry would like to have a copy of the most recent version of the paper you and
Jim Horning wrote, "Towards an Interchange Standard for Editable Documents." 
Our copy is dated 9/18/81.  Can you send us a copy, or tell us where it might be
available?

Thanks, Jan

*start*
00464 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 7-Jan-83 12:48:32 PST
Categories: InterScript
Date:  7-Jan-83 12:48:28 PST
From: mitchell.pa
Subject: Re: Request for Paper
In-reply-to: Your message of 7 Jan. 1983 11:52 am PST (Friday)
To: Murphy.pa
cc: Mitchell

I issued a new version of that paper at the end of August, 1982.  You can find its press file on [Indigo]<Interscript>Aug82>Interscript-aug82.press.  It is about 47 hardcopy pages.

Jim Mitchell
*start*
01385 00098 US 
gvMsgID: Sproull.PA $ 3#20@23-Jan-83 11:46:43 PST
Categories: InterScript
Date: 23 Jan. 1983 11:45 am PST (Sunday)
From: Sproull.PA
Subject: scanning standards subcommittee meeting in el segundo 1/27
To: mitchell,horning
cc: sproull

I've decided I have to go because I've been jumped -- full interpress
has a whole bunch of stuff about scanning, and these guys have gone
and appointed themselves scanning standardizers.  They feel the
real client is interscript, not interpress, so you might be wary too.
Bob

---------------------------

Date: 21 Jan. 1983 5:22 pm EST (Friday)
From: Bhushan.WBST
Subject: Re: Interpress and scanning
In-reply-to: Sproull.PA's message of 21 Jan. 1983 9:53 am PST (Friday)
To: Sproull.PA
cc: Bhushan, Wyatt.PA

Bob,

Your presence will be very beneficial and I will put you on the agenda.  Any
idea if some one from PARC should also attend re. Interscript, so we can get all
this together.  I had asked Townsend and Linden re. participation in the meeting,
and they suggested Mendelson and Curry (I had you and Mitchell/Horning also
as the suggested representatives for Interpress and Interscript).  PARC is welcome
to send representative to the meeting at any time on any subject.  Please let me
know if we need some PARC attendee for Interscript.

Thanks

Abhay

------------------------------------------------------------

*start*
00591 00100 US 
gvMsgID: mitchell.pa $ 3#171@27-Jan-83 15:38:18 PST
Categories: InterScript
Date: 27-Jan-83 15:37:15 PST
From: mitchell.pa
Subject: Re: How an editor internalizes a script
In-reply-to: Your message of 3 Nov. 1982 12:36 pm PST (Wednesday)
To: Mitchell.pa

Take advantage of the fact that acquiring the relevant attributes for a node's record can be batched.  Present a list of the names to be bound and get back a list with the corresponding values in it.  Then the converter pulses through this list lading the record.  For even more efficiency, sort the input list.
*start*
01945 00099 US 
gvMsgID: Linden.pa $ 60#166@ 2-Feb-83 17:43:05 PST
Categories: InterScript
Date:  2-Feb-83 17:45:39 PST (Wednesday)
From: Linden.pa
Subject: Doc Interchange Subcommittee meeting Feb 15
To: ESmura.es, Horning.pa, Kelley.dlos, lynch, Oestreicher, Pierce.dlos, Ayers, Bhushan.wbst, Elkind, Mitchell, Seto.es, Wheeler.wbst, delaBeaujardiere 
cc: Blake.rx, Gittins.rx, Farmer.eos, Kawada.es, Murphy, Strassmann.sthq, Linden.pa, (Wally Swanstrom)DlosMail.dlos
Reply-To: Linden.pa 

Tuesday, February 15, in Palo Alto from 10:00 to 4:00.  Sorry for the short notice.

For those of you who may not have heard, I am the new Chairman of the Subcommittee.


A more detailed agenda will follow, but topics to be covered are:

The status of Interscript:  Roughly, the status is that the key members of the
	Interscript technical working group are planning an intensive period of
	work during March with a goal of producing a draft Xerox standard proposal
	which is complete in the area of text interchange (graphics, scanned
	images, voice, etc. would be later additions).

Reports on external document interchange standards work.  Those of you with things to report here, please send me brief statements of your agenda items.

Discussion leading toward crisp statements on topics such as:

	Do we want to influence external document interchange standards and if so
	how?  Are there areas where it would be beneficial to us if they used
	concepts or constructs compatible with those in Interscript. 

	What effects might external standards work and IBM's announcement of
	Document Interchange and Document Content Architectures have on our
	Interscript work.  What exactly is the role of Interscript in the context
	of these other standards.  (I would like to get an agreement on this role
	which is well enough articulated so Xerox can counteract IBM's
	message that they are in the lead on this issue!)   

Other topics?   

  




*start*
00384 00097 US 
gvMsgID: Ayers.pa $ 60#91@ 7-Feb-83 20:29:47 PST
Categories: InterScript
Date:  7-Feb-83 20:29:43 PST (Monday)
From: Ayers.pa
Subject: March
To: Mitchell

Having not heard anything from you-all, and seeing a reasonably strong SDD Interscript committment, I assume we-all are "on" for logical-March with BWL.

Do we have the proposed weeks picked out yet?

Bob
*start*
00536 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 8-Feb-83 15:55:45 PST
Categories: InterScript
Date:  8-Feb-83 15:55:29 PST
From: mitchell.pa
Subject: Re: March
In-reply-to: Your message of 7-Feb-83 20:29:43 PST (Monday)
To: Ayers.pa
cc: Mitchell

I have as yet heard nothing about SDD's commitment, but I thought that we three had already agreed to use the first two and last two weeks of March as "logical March" with the middle week (Mar 14-18) off.  Has anyone in SDD contacted Butler about this commitment on their part?

Jim
*start*
00327 00097 US 
gvMsgID: Ayers.pa $ 60#91@ 8-Feb-83 18:28:42 PST
Categories: InterScript
Date:  8-Feb-83 18:28:42 PST (Tuesday)
From: Ayers.pa
Subject: Re: March
In-reply-to: mitchell's message of 8-Feb-83 15:55:29 PST
To: mitchell

I've talked with Weaver and Shoch; I am sure that Shoch and Butler have discussed it.
*start*
00917 00100 US 
gvMsgID: mitchell.pa $ 3#171@11-Feb-83 11:48:30 PST
Categories: InterScript
Date: 11-Feb-83 11:47:00 PST
From: mitchell.pa
Subject: meeting with John Shoch
To: Ayers
cc: Lampson, mitchell.pa

Bob,

I have arranged a meeting with John Shoch to discuss the March Interscript Offensive for Monday, February 14 at 3:00 p.m. in my office.  I think it would be good if you could be there too.

I expect to come out of the meeting with a commitment from John that
   (1) Star will use Interscript "soon"; 
   (2) he and you agree that you can spend four weeks on it in March; 
   (3) he agrees to supply ample and appropriate resources to finish the standard in SDD.

I believe (1) and (2) represent the gating function for Butler's participation in developing a text-only standard in March.  (3) is needed to ensure that (1) can be accomplished.

Comments appreciated.  I hope you can make it.

Jim
*start*
01106 00100 US 
gvMsgID: mitchell.pa $ 3#171@16-Feb-83 11:13:12 PST
Categories: InterScript
Date: 16-Feb-83 11:13:24 PST
From: mitchell.pa
Subject: March Interscript Offensive
To: Lampson
cc: Ayers, Horning, Taylor, Linden, mitchell.pa

Butler,

I have discussed your proposed schedule for the March Interscript Offensive with Bob Ayers, and he says it presents no problem for him.  I have not yet heard from the folks at the University of Strathclyde about meeting in March to prepare for the Summer Course they have asked me to lecture at, so they lose in any timing conflict.  Accordingly, the schedule is

    28Feb-4Mar: MIO
    7Mar-11Mar: free
    14Mar-25Mar: MIO (2 weeks)
    28Mar-1Apr: free
    4Apr-8Apr: MIO
    
Jim Horning has said he will be available during the above periods to help in a consulting role;  his only other strong commitment during that time is preparing the LRP (this year called the Strategic Plan) with Mike Schroeder.

Best regards,

Jim

P.S.  I will be out of town all next week, so if you need to contact me, it will have to be this week or on 28 February.

*start*
01071 00100 US 
gvMsgID: mitchell.pa $ 3#171@18-Feb-83 16:38:09 PST
Categories: InterScript
Date: 18-Feb-83 16:38:03 PST
From: mitchell.pa
Subject: The March Interscript Offensive
To: Lampson, Ayers
cc: Horning, mitchell.pa

Butler and Bob,

I will be out of town all of next week, so I though I had better attempt synchronization now.  I propose we meet on Monday, February 28 at 9:00 a.m. in Butler's office and that the first order of business be to sketch out what we hope to have by the end of the MIO.  How does that sound?  I considered going away from PARC/SDD, but decided against it because we will have to work here for most of the period anyway, and we might as well learn to say no to other requests right away.

Butler, 

I have reserved a pool Dorado, whose terminal will be put in your office, for the MIO so you will have a writing machine and we will have a note taker when necessary.

See you then,

Jim

P.S.  I think it would be great if Jim Horning could participate on February 28 and as a "consultant" from time to time during the period.
*start*
03454 00101 US 
gvMsgID: Schwartz.pa $ 60#107@28-Feb-83 10:16:11 PST
Categories: InterScript
Date: 28-Feb-83 10:16:41 PST (Monday)
From: Schwartz.pa
Subject: Control Characters in mail notes (and cover sheets in general) (see OS Software AR 13017)
To: ESMura.es, UIBMembers^.pa
cc: PrintStds^.es, DocStandards^.pa, Garlick, Redell, Ladner, Alfvin.es, Becker, Nikora.es, Artibee, Bishop, Casey, Muirhead, Porcar, Thatcher, Schwartz.pa, Steinbach

The NS Character Set does not address Control Characters (e.g. Character Set Zero characters with octal value under 40B).  According to Joe Becker, this is because such characters are considered device-dependent.

This is all well and good, except that workstations (both Star and ITS terminals, among potential others such as the 860) MUST include such characters in mail notes in order to control the presentation of data at the user terminal.

I am not aware of any well-defined standard which describes which control codes represent which presentation conventions, and which do not.  Treating Character Set Zero as essentially ASCII, there are some pretty good guesses which one can make (and which most of our software HAS made).  For example, an octal 15 is a Carriage Return (CR), and it is obvious what to do with it.

However, other characters are not so obvious.  In the case at hand, consider what happens if the Star user hits the (non-shifted) return key while composing a mail note.  This key is normally a "New Paragraph" key, and Star appears to wish to distinguish this key from a shifted return key.  The latter is sent as an octal 15, but the former is sent as an octal 35, which corresponds to an ASCII Group Separator (GS).  At the Star display, the result of hitting one of these two keys is indistinguishable from the result of hitting the other.

When such a mail note is sent to a workstation other than Star, the behavior of such a workstation is unpredictable, since there is no standard.  For common values such as 15 (CR), a "reasonable" implementor will probably do "the right thing".  But for characters such as GS, there is NOT an established convention.

I propose a short-term and a long-term solution:

Short-term:  We need to agree on a subset of the control characters and their associated semantics, and all workstations (Star and ITS for now) must map all keystrokes into NS characters plus this subset of control characters.

Long-term:  We need to produce a standard which addresses control characters and their semantics.

The short-term problem is particularly urgent in regard to the semantics associated with Star's shifted vs. non-shifted return key in mail notes.  Since it is EASIER to type a non-shifted return key, and since Star gives the user the same feed-back for both actions, I believe that many users will prepare mail notes with the non-shifted return key.

However, a Group Separator (GS) is NOT one of the well-defined ASCII characters, and it does NOT result in a carriage return at an ITS terminal.

I propose that for OS 4.0, Star be modified to convert a non-shifted return key into an octal 15 when such a keystroke is directed at a mail note (or other cover sheet field).  Note that Star is ALREADY performing data conversion operations in preparing mail notes, since much other formatting and display properties (bold, italics, etc.) must be stripped from Star documents when they are moved into cover sheet fields.

Victor Schwartz
*start*
01601 00097 US 
gvMsgID: Ayers.PA $ 60#91@28-Feb-83 16:53:13 PST
Categories: InterScript
Date: 28-Feb-83 16:53:53 PST (Monday)
From: Ayers.PA
Subject: Re: Control Characters in mail notes (and cover sheets in general)
In-reply-to: Schwartz's message of 28-Feb-83 10:16:41 PST (Monday)
To: Schwartz
cc: ESMura.es, UIBMembers^, PrintStds^.es, DocStandards^, Garlick, Redell, Ladner, Alfvin.es, Becker, Nikora.es, Artibee, Bishop, Casey, Muirhead, Porcar, Thatcher, Steinbach

The issue is difficult.  

    For example, you state that "an octal 15 is a Carriage Return (CR), 
    and it is obvious what to do with it"  

    Well it isn't "obvious what to do with it," and standards boards 
    have wrestled with this character for over a decade.  American 
    National Standard X3.4-1977 (ASCII) states:

        0/13 CR (Carriage Return (Return)). A format effector that
        moves the active position to the first character position
        on the same line.
    
    which is probably not what you had in mind as the "obvious."

Ed (Smura) is currently engaged in creating a "control code" standard within the Xerox charcter code set.  Such a standardization is important for inter-network mail and teletex exchange. 

In the absence of a standard, I believe that it is inappropriate to claim that

    We [who?] need to agree on a subset of the control characters and 
    their associated semantics, and all workstations (Star and ITS for 
    now) [860? 820?] must map all keystrokes [ESC on a TTY? Backspace?] 
    into NS characters plus this subset of control characters." 

Bob 
*start*
01171 00101 US 
gvMsgID: Schwartz.pa $ 60#107@28-Feb-83 17:16:27 PST
Categories: InterScript
Date: 28-Feb-83 17:16:38 PST (Monday)
From: Schwartz.pa
Subject: Re: Control Characters in mail notes (and cover sheets in general)
In-reply-to: Ayers' message of 28-Feb-83 16:53:53 PST (Monday)
To: Ayers
cc: ESMura.es, UIBMembers^, PrintStds^.es, DocStandards^, Garlick, Redell, Ladner, Alfvin.es, Becker, Nikora.es, Artibee, Bishop, Casey, Muirhead, Porcar, Thatcher, Steinbach, Schwartz

Bob,

Thanx for your comments.

I realize that I over-simplified, and that the Long-term solution is even tougher than I described.  But in the absence of Ed Smura's "control code" standard, would you propose that NO changes be made in OS 4.0?  The result of this is that most mail notes sent by Star to ITS terminals won't look anything like they did on the Star screen.  Line breaks will be RANDOM, based on screen width, rather than matching the places where the Star operator entered a (non-shifted) return key.

It seems that at least this one glaring ugly needs to be addressed, and hopefully in a manner consistent with our "best guess" at the long-term solution.

Victor
*start*
00962 00098 US 
gvMsgID: Pellar.es $ 46#92@28-Feb-83 17:21:16 PST
Categories: InterScript
Date: 28 Feb. 1983 5:21 pm PST (Monday)
From: Pellar.es
Subject: Re: Control Characters in mail notes (and cover sheets in general) (see
 OS Software AR 13017)
In-reply-to: Schwartz.pa's message of 28-Feb-83 10:16:41 PST (Monday)
To: Schwartz.pa
cc: ESMura, UIBMembers^.pa, PrintStds^, DocStandards^.pa, Garlick.pa, Redell.pa,
 Ladner.pa, Alfvin, Becker.pa, Nikora, Artibee.pa, Bishop.pa, Casey.pa,
 Muirhead.pa, Porcar.pa, Thatcher.pa, Steinbach.pa
Reply-To: Pellar

The question of a Xerox Control Standard has been referred to the Printing
Standards Sub-Committee. I am in aggreement that one is needed. However, full
consideration and some kind of compatibility with the existing ANSI and ISO
standards is essential. The pertinent ISO standards are ISO 646, ISO 2022, ISO
6429.2 and ISO 2375. The ANSI standards are X3.4, X3.28, X3.32, X3.41, and X3.64.

Ron

*start*
01599 00101 US 
gvMsgID: pierce.dlos $ 19#130@ 2-Mar-83 11:45:59 PST
Categories: InterScript
From: pierce.dlos
Date:  2-Mar-83 13:46:00 CST
Subject: Re: Control Characters in mail notes (and cover sheets in general)
In-reply-to: Ayers.PA's message of 28-Feb-83 16:53:53 PST (Monday)
To: Ayers.PA
cc: Schwartz.PA, ESMura.es, UIBMembers^.PA, PrintStds^.es, DocStandards^.PA, Garlick.PA, Redell.PA, Ladner.PA, Alfvin.es, Becker.PA, Nikora.es, Artibee.PA, Bishop.PA, Casey.PA, Muirhead.PA, Porcar.PA, Thatcher.PA, Steinbach.PA

Bob,

A standard that is currently in the last "throes" of approval is the ANSI Standard called Text Image Format.  This standard defines explicitly the functions and performance of control characters, such as CR (Carriage Return.  In addition to this format control code, there are several new control codes that have not been part of the "teleprinter" ASCII protocol.  These 
control codes have also been explicitly defined and the codes assigned.

In addition, there is a new standard that builds upon TIF called BPTIF.
This standard adds even more format or layout control codes and is the latest
submission by ANSI.  A key ingredient of this new standard is the concept of a 
Master Format Header that precedes the document with control
codes that appear within the document that point back to this Master Format Section when applicable.  The definitions of the new control codes are available.

This information may be pertinent to the discussions I previously read
on the network.

Let me know if I can provide additional information that you might need.

Roy
*start*
01600 00099 US 
gvMsgID: gcurry.es $ 60#161@ 3-Mar-83 10:31:17 PST
Categories: InterScript
Date:  3-Mar-83 10:31:19 PST (Thursday)
From: gcurry.es
Subject: Interscript Base language for Global Selections ?
To: StarArchInterest^.es, Interscript.pa, Newlin.pa, Wolf.pa
Reply-To: gcurry.es

In a discussion regarding the treatment of global selections in the reworked Star, it became apparent that the problem of exchanging document "values" between different editors was much like the problem of exchanging other, smaller values (like text, graphics entities or frames) between applications of different types running in different windows on the same workstation.

An integrated workstation environment, for example, gets a lot of mileage out of treating "textual" values occuring in different applications as a universal type, just as an integrated network environment gets a lot of mileage out of treating "document" values as a universal type.  It is certainly possible to think of other universal types.

Perhaps the Interscript base language would be a good way to think of representing these universally understood values in the global selection.  That is, if asked, a selection could report on its value in Interscriptese.  Doing so would systematize the treatment of globally selected values, and encourage the exchange of structured values between domains of different types.

It would also be a good "proving ground" for developing Interscript representations for non-standard domains like graphics, equations, etc (which must eventually make it into the Interscript standard).

Gael
*start*
02439 00098 US 
gvMsgID: Pettit.PA $ 60#93@ 3-Mar-83 11:30:03 PST
Categories: InterScript
Date:  3-Mar-83 11:30:22 PST (Thursday)
From: Pettit.PA
Subject: Re: Interscript Base language for Global Selections ?
In-reply-to: gcurry.es's message of 3-Mar-83 10:31:19 PST (Thursday)
To: GCurry.ES
cc: StarArchInterest^.ES, Interscript.PA, Newlin.PA, Wolf.PA
Reply-To: StarArchInterest^.ES, Interscript.PA

I hope something like this is made part of the design.  Currently in Star the destination (buttonup processor) of a MOVE/COPY does just about all the work, which includes knowing how to "read" the source seltype and translate it into its own format.  This makes for a lot of asymmetry in what inter-application exchanges are allowed.  For example, you can MOVE/COPY a text selection (stripped of its tiles and formatting characters) into an equation, but you can't MOVE/COPY anything from an equation into text.  This is because the equation code accepts the task of translating text segments into equation schemas, but the text code rejects equation selections.  A base language for representing selections would even out a lot of this responsibility.

Another problem with the current Star design for MOVE is that besides translating the source selection, the destination application must also do the deletion of the source, in an application-specific way!  Thus we have equation's AcceptMoveOrCopy setting up a TxtEditDefs.AqTxtCtxt and calling TxtEditDefs.AdjustDeleteSpan, BeginEdit, Delete, and EndEdit when a text selection is moved into an equation.  While it makes sense for the destination to have responsibility for initiating the deletion (so that the source can "disappear" after it has been judged acceptable by the destination but before the translation of it is inserted), it should be able to initiate that deletion via an interface which is independent of the source seltype.

By the way, I'm very interested in a lot of the PAP issues, but have been paying little attention to the StarArchInterest interchanges because I'm swamped with OS 4 work.  So I want to second what some of the other Star implementors have said, that lack of input from us at this time should not be taken as evidence that we've examined the proposals and judged them adequate for our areas.  When OS 4 goes out the door, you will see a lot of the heretofore Silent Majority getting heavily involved in the Ground Floor design.

-- Teri
*start*
00580 00113 US 
gvMsgID: Ralph.London@CMU-CS-A.ARPA $ 3#5@ 5-Mar-83 10:21:55 PST
Categories: InterScript
Received: from CMU-CS-A.ARPA by PARC-MAXC.ARPA;  5 MAR 83 10:21:29 PST
Date: 5 Mar 83 13:18 EST (Saturday)
From: Ralph.London@CMU-CS-A.ARPA
To: Mitchell.PA
Subject: Abrahams Problem
CC: Ralph.London@CMU-CS-A.ARPA
Message-Id: <05Mar83 131824 RL10@CMU-CS-A>

Jim,

After you talked about Interscript we were discussing a problem Paul Abrahams
published in Sigplan Notices involving text formatting.  The problem appeared
in the Feb., 1976 issue, pp. 17-19.

					Ralph
*start*
00932 00100 US 
gvMsgID: Ingalls.PA $ 16#108@ 7-Mar-83  9:35:16 PST
Categories: InterScript
Date: 7 March 1983 9:35 am PST (Monday)
From: Ingalls.PA
Subject: Text from other sources
To: ComputerResearch^, HomeComputing^
cc: Junk^
Reply-To: Ingalls

Several people have asked me questions of the form: "How do I get a file from my
XYZ computer onto an Alto, or a STAR (or vice-versa)?"

So I would like to hear from anyone who knows how do this for various external
sources.  Of special interest are IBM PCs and Apples.

Fill in the following form or reasonable facsimile (as many copies as you wish),
and I'll make the results available to those interested.

SourceMachine to DestinationMachine
Format details - disk format, data rate, etc.
How - equipment needed, technique used
Is there a setup available?
	If so, where; whom to contact.
	If not, what is needed.
Are you willing to be consulted?  If so, your extension:


*start*
04608 00099 US 
gvMsgID: Horning.pa $ 3#203@ 7-Mar-83 12:45:27 PST
Categories: InterScript
Date:  7-Mar-83 12:45:11 PST
From: Horning.pa
Subject: Towards a Definition of Indirection in Interscript
To: Mitchell, Lampson, Ayers
cc: Horning

I (once again) believe that I understand A semantics for indirection. This message is an attempt to communicate that understanding before I lose that confidence.

I believe that much of our trouble last week resulted from a natural, but dangerous, tendency to confuse the evaluation and canonicalization functions. Two scripts with the same canonical form always have the same value, but not conversely (particularly when indirection and scopes are involved). One reason they are so easy to confuse is that canonicalization must treat un%ed invocations and bindings in a manner quite analogous to evaluation.

Editors must be able to evaluate scripts--for display, rendering, and probably for various editing operations. They are NOT required to canonicalize them--only to be able to produce "equivalent" scripts, where canonicalization is used to DEFINE equivalence.

Consider some functions:
	canonicalize: abstract-script -> canonical-node
	abstract: canonical-node -> abstract-script
		so that canonicalize(abstract(cn)) = cn
	abstract-eval: abstract-script -> value-node

Now, since equivalent scripts must have the same value, we know that abstract-eval can be written as a composition of a function with canonicalize:
	eval: canonical-node -> value-node
		so that abstract-eval(s) = eval(canonicalize(s))

It is also useful to have a function that removes %'s from scripts, producing "direct scripts":
	strip: abstract-script -> abstract-script
and to define an auxilliary function
	direct-eval: abstract-script -> value-node
		so that direct-eval(s) = abstract-eval(strip(s))

THE FUNDAMENTAL PRINCIPLE OF INDIRECTION

	For all s: abstract-eval(s) = direct-eval(s)

This says that "%'s don't affect values." But, of course, they do affect the canonical form, since scripts that differ in %'s aren't equivalent. (Therefore, the space canonical-node must be bigger than the space value-node.)

COMPONENTS OF NODE VALUES (Tags, Labels, etc.)

	X-value-select: canonical-node -> value-X
	X-select: value-node -> value-X
		so that X-value-select(cn) = X-select(eval(cn))
	X-canonical: canonical-node -> canonical-X
	X-eval: canonical-X -> value-X
		so that X-value-select(cn) = X-eval(X-canonical(cn))

SPECIFICATION DOMAIN CHOICES

Of course, we need not keep all these domains distinct. We can reduce the number of functions to be defined, and the conceptual complexity, by identifying some of these domains. The prime candidates are the canonical domains, which have less independent "existence," anyhow. The two obvious choices are:

	Make the canonical domains subsets of abstract scripts. This is the approach I have taken previously; let us call it Script Canonicalization (or Choice A).

	Make the canonical domains supersets of the value domains. I think that this is the approach Butler was advocating last week; let us call it Value Canonicalization (or Choice B).

Note that for either choice we must define canonicalize to "preserve" indirections, and not to contradict the Fundamental Principle. Both choices also require (at least) direct-eval "at run time." One of the charms of Choice B, is that eval is an identity FOR DIRECT SCRIPTS.

CHOICE A: SCRIPT CANONICALIZATION

	CHOOSE canonical-X = canonical-node <= abstract-script
	DEFINE abstract(cn) = cn &
			X-canonical(cn) = cn

	THEREFORE eval(cn) = direct-eval(cn) = abstract-eval(cn) &
			X-eval(cn) = X-select(eval(cn))

This looks pretty straightforward to me. Canonicalize has to be defined by cases over the abstract syntax, and proceeds pretty much like eval, except that %ed bindings don't get distributed, and %ed invocations don't get evaluated (hence, constructs in which they appear--including scopes--don't get folded).

CHOICE B: VALUE CANONICALIZATION

	CHOOSE canonical-node >= value-node, canonical-X >= value-X
	DEFINE canonicalize(strip(s)) = direct-eval(s) &
			X-canonical(direct-eval(s)) = X-select(direct-eval(s))

	THEREFORE eval(cn) = direct-eval(abstract(cn)) & . . .

[I'm afraid I don't see where to take this approach. It works like a charm for direct nodes, where the canonical representation is the value, but not so well in the presence of indirection. I think Butler's idea was to restrict the use of % so that the composition direct-eval(abstract()) would be an easily-evaluated function. Every time I've tried to do this I've gotten confused.]

Jim H.

*start*
03015 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 7-Mar-83 13:32:43 PST
Categories: InterScript
Date:  7-Mar-83 13:32:40 PST
From: mitchell.pa
Subject: Butler's whiteboard as of 3/4/83
To: Lampson, Ayers, Horning
cc: mitchell.pa

Here is my rendition of the information that was on Butler's whiteboard at the end of last week.  I have added hints about how we resolved the issues that we had dealt with just to jog our memories.  If I have missed or misrepresented anything, let me know.

Jim

Standards Document:
    Language Definition
    Unique names
    Encodings
    Environment
    Pragmatics
    Text, Paragraph Layout
    INTERPRESS$
    Other Constructs
    
Introduction to Interscript
    Explanation
    How to achieve various effects
    
Implementor's Guide
    Internalization
    Externalization
    Editing
    Rendering
    
Issues Remaining:  Difficulty(Low, Medium, High)/week:   ISSUE
    L/2: meaning of multiple tags
    L/2: Do we model all the Interpress imaging stuff adequately?
    M/2: Tables
    M/2: Tabs
    M/2: semantic functions (equivalence of scripts)
    H/2: pouring algorithm and attribute disjunctions
    H/2: specifying layout/formalizing geometry
    H/2: Indirection
    
    L/4: do we want well-known styles (e.g., IndentedParagraph)
    L/4: how to display unique names
    L/4: minimal conforming editor requirements?
    M/4: Size limits on RHSs? constant RHSs?
    M/4: medium selection and other "printing instructions"
    M/4: Restore invariants when changing external environment?
    
Issues already dealt with:
    L/1: number of bindings per scope
         Resol'n: Multiple, last one wins for that scope; subnodes see current bindings
    L/1: naming env. items
         Resol'n: use long hierarchical names
    L/1: scope of global bindings
        Resol'n: use global bindings; separate name space; use explicit stacking/unstacking
    M/1: Tag-independent operatiions (e.g., Delete, Copy, Move)
         Resol'n: leave unchanged => preserve bindings of all relevant attributes;
         don't mess with direct contents; preserve parent's tag(s) ?
    M/1: understand => can display; will ensure invariant (leaving unchanged)
         Resol'n (partial): invariants must be compartmentalized w.r.t. tags; relevant attributes,
         types; content types; predicate over direct (untagged) content and attribute values;
         parent tags
    M/1: are there levels of the base language? (links, indirection, "large" exprs)
         Resol'n: see about links below; indirection and "large" exprs issues deferred.
    M/1: Baselines and Interpress stuff versus tags
         Resol'n: Ayers will write in Ch.4 using Knuth TEX stuff, p.58
    H/2: meaning of links, uses in standard (fill-in rules, indexable items, figure refs)
         Resol'n: keep only the labelling part of links and throw out "LINKS" and ^


Other items (top of BWL's board):
    Proof scripts
    Standard editing ops to define tag semantics
    No tags => (manifest = relevant)
*start*
00940 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 7-Mar-83 19:24:02 PST
Categories: InterScript
Date:  7 Mar 83 19:24:05 PST (Monday)
From: Ayers.PA
Subject: Standards Document that We Should Have (perhaps multiple copies)
To: Library
cc: Mitchell, Lampson, Newlin, Sproull
cc: deLaBeaujardiere, Ayers

NAPLPS, the North American Presentation-Level-Protocol Syntax, is a draft standard within ANSI X3L2.

Is is amazingly like Interpress82 with an encoding that satisfies ISO-646+

There is a major article on this standard in the February/March/April 1983 Byte.

The draft proposed standard can (according to Byte article) be obtained (for $18) by requesting document #BSRX3.110-198X from:

    CBEMA (Computer and Business Equipment Manufacturers Asociation)
    X3 Secretariat, Suite 500
    311 First St. NW, 
    Washington D.C. 20001
    
The library definitely needs a copy.  I would like a copy to hang on to; others may also.

Bob
*start*
00461 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 8-Mar-83 11:10:09 PST
Categories: InterScript
Date:  8-Mar-83 11:10:04 PST
From: mitchell.pa
Subject: Re: Standards Document that We Should Have (perhaps multiple copies)
In-reply-to: Ayers' message of 7 Mar 83 19:24:05 PST (Monday)
To: Library
cc: Mitchell

I would like to have a copy of NAPLPS, the North American Presentation-Level-Protocol Syntax to hang onto (document #BSRX3.110-198X).

Jim Mitchell
*start*
01206 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 8-Mar-83 18:38:58 PST
Categories: InterScript
Date:  8 Mar 83 18:38:59 PST (Tuesday)
From: Ayers.PA
Subject: Absence of Cedar-success
To: Mitchell, Horning, McGregor (is there an 'official' support group?) 
cc: Ayers

So far it looks like Cedar is not an editing environment.

I crash it every couple of actions.  Because I don't know what to avoid?

My nth difficulty left my disk in a bad state:

    Tried to print [indigo]<cedar>documentation>tsetter.tioga via TSetter
    [was looking at it thru Tioga at the time]
    
    System died .. no notifier (a standard way for Cedar to die, tho I've 
    hit 915, too .. nver have landed in CoPilot.]
    
    Rebooted Client: system fell into loop while booting.
    
    Swatted and booted Client from CoPilot
    
    System booted ok; tried to print [indigo]<cedar>documentation>tsetter.tioga
    and get the complaint "[indigo]<cedar>documentation>tsetter.tioga is busy"
    
    Can't make that complaint go away.
    
I will try to boot once more, but the above is only one of the scenes that has been played on my Dorado today, and Star is looking better and better as an editing environment.

Bob
*start*
00954 00099 US 
gvMsgID: Horning.pa $ 3#203@ 8-Mar-83 19:04:52 PST
Categories: InterScript
Date:  8-Mar-83 19:04:48 PST
From: Horning.pa
Subject: Re: Absence of Cedar-success
In-reply-to: Ayers' message of 8 Mar 83 18:38:59 PST (Tuesday)
To: Ayers.pa
cc: Mitchell, Horning, McGregor

"is there an 'official' support group?" CedarSupport^, TiogaImplementors^

I've never tried to TSet a remote document. Try bringing it over and then TSetting it.

915 usually means that it doesn't think you have a CoPilot. Might check the volume allocation with Othello.

There's clearly an evolutionary process (cf. Weinberg) at work here: users evolve to not provoke bugs, and systems evolve to not have the bugs that their user set finds most offensive. But you haven't yet had the benefit of either form of the evolution. I can edit with Tioga for hours between crashes. My wife averages more like 45 minutes (and only tries the "simple" features).

Jim H.

*start*
01061 00100 US 
gvMsgID: McGregor.pa $ 3#223@ 9-Mar-83 10:40:31 PST
Categories: InterScript
Date:  9-Mar-83 10:40:28 PST
From: McGregor.pa
Subject: Re: Absence of Cedar-success
In-reply-to: Ayers' message of 8 Mar 83 18:38:59 PST (Tuesday)
To: Ayers.pa
cc: Mitchell, Horning, McGregor (is there an 'official' support group?)

Bob;

Sorry to hear you've been having trouble.  Perhaps Jim Horning's "system evolution" theory explains some of your problems, but here are some other hints:

The TSetter is a known source of trouble.  I suggest that you only run it to typeset local Tioga files.  We are completely replacing the TSetter in the next version of Cedar.

Your 915 problem means that you probably have an incorrectly installed debugger volume and/or that you booted Cedar with the R(emote debug) switch; I suggest reinstalling CoPilot or rebooting the Client volume without the R switch.

As for the general "I crash it every couple of actions", I'd be interested.  Can you try and remember what you last did and give me a call?

Thanks,

Scott.
*start*
03132 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 9-Mar-83 12:09:16 PST
Categories: InterScript
Date:  9 Mar 83 12:09:19 PST (Wednesday)
From: Ayers.PA
Subject: MIO: Section Four Continues to be a Star Document
To: Mitchell, Horning, Lampson
cc: Ayers, Sturgis

I have now spent about five hours trying to run Cedar on Midway.  The results have been depressing.  Perhaps hardware is to blame.  

I ran yesterday evening, and got Howard Sturgis to show me some things.  Howard was surprised by the difficulties he encountered, but we managed to get an "ayers" user profile installed and do a bit of Tioga typing.

Here's todays session summary:

    9:48: pppBoot/CoPilot/Client => into CoPilot ds=traps/RTProcessImpl/Traps*
    
    9:53: boot/Client via herald => got tree into cursor, looped there.
    
   10:00: pppBoot/CoPilot/Client => into CoPilot with ds
          traps/RTAllocatorImpl/RopeImpl/AtomsPrivateImpl/RTLoaderImpl ...
	  
   10:03: pppBoot/CoPilot/Client => running at 10:07!
   
          Brought up Tioga on old "tiogaTryFrom860" -- ok. Brought 
          up Tioga on "tiogaTryFrom860-Sturgis" document via "open"
          Only first line displayed.  Lost Notifier.
	  
   10:12: pppBoot/Client => CoPilot with ds=Traps/HourglassImpl/Traps.
   
   10:15: pppBoot/CoPilot/Client => running at 10:18!
   
          Opened filetool, displayed *860* to get names, accidently
	  selected all of lower window (multiclicked yellow). Couldn't get
	  back to small selection by clicking; clicked as "DFFile" to try 
	  and make selection go away, it went gray, got screen blink,
	  lost Notifier.
	  
   10:21: pppBoot/CoPilot/Cient => died early with white screen
   
   10:26: pppBoot/CoPilot/Cient => into CoPilot with ds
          Traps/RTZonesImpl/CedarExporter/CedarExporter/BcdOperations/
	  CedarExporter* ...
   
   10:30: pppBoot/CoPilot/Cient => running! 
	  
	  Brought up Tioga on "tiogaTryFrom860-Sturgis" and got it!
	  Edited in Tioga, inserting new paras and deleting 860-garbage.
	  Copied InterscriptDocumentation.style_TiogaDoc.style and
	  changed document to use that style.  Printed to see first
	  couple of new pages.  
	  
	  Opened Exec and lost notifier @ 11:00.  [Daniels and Sandman
	  happened to be watching and poked around after swatting to
	  CoPilot and reported a stack underflow in STLeafImpl ?!?]
	  
   11:08: boot/Client from herald.  Got past where clock comes up
          but no Tioga window appeared -- stuck with hourglass.
	  
   11:13: pppBoot/CoPilot/Client => seemed ok.
   
          Opened filetool: all typein shows caret, positioned too high, 
	  moving to right, but no characters appear.
	  Closed and reopened filetool: no typein shows caret too high, 
	  and gives black garbage at top of line
	 
Considering that the above (yesterday was similar) is zero productivity, and that Cedar usage was supposed to be the easy part [it wasn't until I got into Tioga and no wysiwyg, jam-for-styles, no illustrations, that I was supposed to get depressed] and that I'm supposed to have section four redone before next week's meetings, I'm retreating to Star.

Bob 
	  
*start*
01541 00098 US 
gvMsgID: Wilder.PA $ 20#79@11-Mar-83  9:15:22 PST
Categories: InterScript
Date: 11 March 1983 9:15 am PST (Friday)
From: Wilder.PA
Subject: NAPLPS
To: Ayers
cc: Mitchell, Lampson, Newlin, Sproull, Lavendel, KJarvis, Pindar

I have already ordered one for the library - will order a few extras today.
		Alice

---------------------------

Date: 10 March 1983 1:45 pm PST (Thursday)
From: Library.PA
Subject: Standards Document that We Should Have (perhaps multiple copies)
To: Lavendel, Wilder, KJarvis, Pindar
cc: 

FYI

---------------------------

Date:  7 Mar 83 19:24:05 PST (Monday)
From: Ayers.PA
Subject: Standards Document that We Should Have (perhaps multiple copies)
To: Library
cc: Mitchell, Lampson, Newlin, Sproull
cc: deLaBeaujardiere, Ayers

NAPLPS, the North American Presentation-Level-Protocol Syntax, is a draft
standard within ANSI X3L2.

Is is amazingly like Interpress82 with an encoding that satisfies ISO-646+

There is a major article on this standard in the February/March/April 1983 Byte.

The draft proposed standard can (according to Byte article) be obtained (for $18)
by requesting document #BSRX3.110-198X from:

    CBEMA (Computer and Business Equipment Manufacturers Asociation)
    X3 Secretariat, Suite 500
    311 First St. NW, 
    Washington D.C. 20001
    
The library definitely needs a copy.  I would like a copy to hang on to; others
may also.

Bob
------------------------------------------------------------

------------------------------------------------------------

*start*
01018 00099 US 
gvMsgID: Sosinski.PA $ 3#75@11-Mar-83 12:29:26 PST
Categories: InterScript
Date: 11 March 1983 12:29 pm PST (Friday)
From: Sosinski.PA
Subject: Midway in Hot Water
To: Mitchell, Sturgis, Schmidt, Ayers, Clark, Daniels
cc: Yeary, Sosinski, Ornstein

The "Midway" is room 100 of Building 96.  The ambient temperature in this room
is about 85 degrees farenheit, which is way out of specs!  It is a miracle that this
dorado run at all!  A lot of "hot iron" has been installed in this room since the
dorado installation.  

Unfortunately, Building 96 is not a PARC building and our A/C guys are not
responsible for it.  We are still pursuing those responsible.  It is my
recommendation that the Midway be shutdown if the temperature is not brought
back in specifications by next week.

I don't think the Midway is a "blackeye" to CSL.  I think it is a "miracle
machine".  By opening the chassis and directing a room fan at the intake, the
Midway is able to run Cedar reliably for now.


Charlie




*start*
00510 00100 US 
gvMsgID: ornstein.PA $ 3#231@11-Mar-83 13:36:27 PST
Categories: InterScript
Date: 11 March 1983 1:36 pm PST (Friday)
From: ornstein.PA
Subject: Re: Midway in Hot Water
In-reply-to: Sosinski's message of 11 March 1983 12:29 pm PST (Friday)
To: Sosinski
cc: Mitchell, Sturgis, Schmidt, Ayers, Clark, Daniels, Yeary, Ornstein

This is inexcusable and I support Charlie.  The understanding that we had when
we moved Midway to its "new" room was that it had to be clean and cool.  

Severo

*start*
00417 00097 US 
gvMsgID: Ayers.PA $ 60#91@11-Mar-83 14:35:10 PST
Categories: InterScript
Date: 11 Mar 83 14:35:14 PST (Friday)
From: Ayers.PA
Subject: MIO: Para$ and Box$
To: Mitchell, Horning, Lampson
cc: Ayers

Did we decide that a paragraph node is a box node, e.g.

    { BOX$ PARA$ ... }
    
or did we decide that they are separate?

    { BOX$ ... { PARA$    } }
    
I beleive we liked the latter ...
*start*
00361 00100 US 
gvMsgID: mitchell.pa $ 3#171@11-Mar-83 15:56:50 PST
Categories: InterScript
Date: 11-Mar-83 15:56:34 PST
From: mitchell.pa
Subject: Re: MIO: Para$ and Box$
In-reply-to: Ayers' message of 11 Mar 83 14:35:14 PST (Friday)
To: Ayers.pa
cc: Mitchell, Horning, Lampson

I believe we liked (and I KNOW I like) { BOX$ ... { PARA$    } }

Jim M.
*start*
00561 00097 US 
gvMsgID: Ayers.PA $ 60#91@14-Mar-83 17:25:27 PST
Categories: InterScript
Date: 14 Mar 83 17:25:47 PST (Monday)
From: Ayers.PA
Subject: Anyone know what "WIPO" Is?
To: PrintStds^.es, FontStandards^.wbst

In the current draft X3J6 text processing standard, on page 65, I find this:

    CHARACTER-STYLE = er-strg
        The string expression must evaluate to the name of a family
	of characters such as Helvetica, Elite, or Shcoolbook.
	<<< Make sure that WIPO terminology is used here.>>>
	
Anyone know what "WIPO" is referring to?

Bob
*start*
00875 00097 US 
gvMsgID: Ayers.PA $ 60#91@15-Mar-83 17:27:13 PST
Categories: InterScript
Date: 15 Mar 83 17:27:19 PST (Tuesday)
From: Ayers.PA
Subject: On synthesized vs Inherited Dimensions: Taxonomy Failure
To: Horning, Mitchell, Lampson
cc: Ayers

The paragraph-box, if we had one: 
    height is synthesized; 
    width is inherited; 
    "layoutProceeds" within it is top-to-bottom.

The column-box and footnote-box:  
    Height is partly synthesized and partly inherited; 
    width is inherited; 
    "layoutProceeds" within it is top-to-bottom.

The (vanilla) line-box: 
    height is synthesized; 
    width is inherited; 
    "layoutProceeds" within it is left-to-right.
    
I tried for a statement that said that many boxes had one synthetic and one inherited dimension, and that which was which was governed by "layoutProceeds" but I didn't succeed.



*start*
00618 00103 US 
gvMsgID: Leibowitz.WBST $ 23#76@17-Mar-83 20:02:06 PST
Categories: InterScript
Date: 17 March 1983 11:05 pm EST (Thursday)
From: Leibowitz.WBST
Subject: Re: Anyone know what "WIPO" Is?
In-reply-to: Ayers.PA's message of 14 Mar 83 17:25:47 PST (Monday)
To: Ayers.PA
cc: PrintStds^.es, FontStandards^
Reply-To: Leibowitz.WBST

WIPO = World Intellectual Property Organization  in Geneva, Switzerland

also known as

OMPI = Organisation Mondiale de la Propriete Intellectuelle

whose function is the registration of all types of proprietary designs,
including typefaces and their names.

	-- Mike

*start*
02547 00096 US 
gvMsgID: Suk.PA $ 60#189@18-Mar-83 16:03:47 PST
Categories: InterScript
Sender: Suk.PA
Date: 18 Mar 83 16:04:59 PST (Friday)
Subject: New Standards Documents
To: OSBU^.es, OSD-ES^.es, CommunicationProtocols^.pa, CourierInterest^.pa, DocumentInterchange^.pa, DocStandards^.pa, FilingInterest^.es, IPDesign^.pa, IPInterest^.pa, PrintServiceInterest^.es, PrintStds^.es, NetStandards^.wbst, ScanStandards^.wbst, ServicesInterest^.es, TelepressDesign^.es, TelepressInterest^.es, BKorbholz.ES
To: P England ESCP P3-16<ESMail.es>, A Lipton ESDS M1-16<ESMail.es>, W White HADB<ESMail.es>
To: M A Henderson DLOS 199<DLOSMail.dlos>, C Jacobson DLOS 129/550<DLOSMail.dlos>, R Pierce DLOS 625A<DLOSMail.dlos>, N Reed DLOS 185<DLOSMail.dlos>, W Swanstrom DLOS 185<DLOSMail.dlos>, R Vance DLOS 134<DLOSMail.dlos>
To: J Shoemaker ROCH 027<MCMail.wbst>, F Steenburgh ROCH 023<MCMail.wbst>, D Wilkie TOHQ 6800<MCMail.wbst>
To: K Oikawa<FXMail.fx>
To: R Stern<Kurzweil>
cc: Drosdek.wbst, Library, Murphy, Warner
From: "OSD Technical Publications"
Reply-To: OSD-Pubs.pa

This is to announce the availability of five new standards documents.  The protocol standards described in these documents have been approved by the System Integration Standards Board (SISB) and are now Xerox Corporate Standards.  For the time being, these documents are all Xerox Private Data, and should be circulated within the company on a NEED-TO-KNOW basis only.

The following documents are now available:

			Title				Date		Pub. No.

Authentication Protocol					Oct, 1982	XSIS 098210

Filing Protocol						Oct, 1982	XSIS 108210

Printing Protocol					Oct, 1982	XSIS 118210

Miscellaneous Standards (so far contains only
	Time Protocol, XSIS 088210, Oct, 1982)		Jan, 1983	XSIS 128301

Addenda to Standards (includes Bulk Data Transfer
	addendum to Courier Std & Interpress Font Names
	addendum to Interpress 82 Standard)		Jan, 1983	XSIS 138301
	

You may request copies of these standards by sending a message to <OSD-Pubs.pa>, and listing the documents you need by name.  However, since these documents are quite costly to produce, we ask you to order them only if you have a definite need. If you are located somewhere other than Palo Alto, please include both your internal mail stop number and your external (USPS) mailing address.


A list of all available standards documents can be found on

	    [Iris]<TPPubs>List>XeroxPrivate.txt

or, for Star users, on

	    [McKinley]<Publications><OSD Publications Lists>Xerox Private.


"OSD Technical Publications"
*start*
02022 00098 US 
gvMsgID: ESMURA.ES $ 44#35@21-Mar-83 11:50:18 PST
Categories: InterScript
Date: 21 March 1983 11:50 am PST (Monday)
From: ESMURA.ES
Subject: Available Documentation
To: pierce.dlos
cc: Schwartz.PA, UIBMembers^.PA, PrintStds^.es, DocStandards^.PA, Garlick.PA,
 Redell.PA, Ladner.PA, Alfvin.es, Becker.PA, Nikora.es, Artibee.PA, Bishop.PA,
 Casey.PA, Muirhead.PA, Porcar.PA, Thatcher.PA, Steinbach.PA
Reply-To: ESMURA

I have received a considerable amount of documentation recently and am willing
to forward it to those interested.  The following might be of interest to some of
you: 

From Graphic Communications Association

1- Publishing From A Full Text Data Base, Second Edition, February 1983, 176
pages- Graphic Syatems Develop. Div., Government Printing Office

2- Canadian Government Generic Typesetting Codes--User's Manual Memo,
November 1982, 22 pages

From X3J6/CLPT Mailing List

1- Proposed Standard Flexible Disk Cartridge Volume and File Structure for
Information Interchange, Working paper by Howard Kaikow of Digital
Equipment, 07 Jan 83, 48 pages

2- Draft Recommendation S.a - A proposal for a new Recommendation which
"defines the presentation control procedures to be used within the Telematic
services when a document structure is required within a page of a document
(mixed mode of operation), 11 pages

3- Proposed Graphic Character sets, X3L2 correspondence including proposed
tables
	a) Technical Graphic Set
	b) Publishing Graphic Set
	c) Box Drawing Graphic Set
	d) Fractions Graphic Set (two alternative codings)

4- ECMA TC1 Position and Japanese Comments on 96-character Sets Issue and
ISO 2022.
A conflict exists between NAPLPS which is a "complete code" and ISO2022. 
NAPLPS uses 96-characters and ISO 94-characters and interpretation of space
(2/0) is in question.

If anyone would like to see any of the above send me your name and mailstop
and what your interested in receiving.  I may circulate or copy, depending on
number of responses and document size.

Ed
*start*
01628 00096 US 
gvMsgID: Suk.PA $ 60#189@21-Mar-83 15:40:55 PST
Categories: InterScript
Sender: Suk.PA
Date: 21 Mar 83 15:41:17 PST (Monday)
Subject: Templates for Standards Documents
To: OSBU^.es, OSD-ES^.es, CommunicationProtocols^.pa, DocStandards^.pa, IPDesign^.pa, PrintStds^.es, NetStandards^.wbst, ScanStandards^.wbst, TelepressDesign^.es, BKorbholz.ES
From: "OSD Technical Publications"
cc: Murphy
Reply-To: OSD-Pubs.pa

Anyone preparing draft standards for submission to the System Integration Standards Board (SISB) or any of its subcommittees is encouraged to use the templates that are now available for standards documents.  These templates can be found on:

For BRAVO users:   [Ibis]<Publications>Format>*    (15 files)

Retrieve [Ibis]<Publications>A>ReadThisFirst>DirectoryIndex.bravo/press
for hints/introduction.

For STAR users:    [Tundra]<Tech Pubs>Star 3.0w-y XSIS Templates

Open the folder and look at the <Template Instructions> for hints/introduction.
(Note: these templates work properly with Star 3.0wr through 3.0yr.  We will update the templates after new software is released, and the folder title will reflect any changes.)

For BRAVO-X users:  We do not have full templates available.  We encourage you to work in Star if at all possible.  If you MUST use BravoX, contact us for individual assistance.

Subcommittee Chairpersons: please forward this message to anyone who might be working on your documents that is not included in the distribution.

Please message <OSD-Pubs.pa> if you have any questions or if you find problems with any of the templates.


"OSD Technical Publications"
*start*
00383 00100 US 
gvMsgID: mitchell.pa $ 3#171@24-Mar-83  9:10:54 PST
Categories: InterScript
Date: 24-Mar-83  9:10:29 PST
From: mitchell.pa
Subject: Remaining "March" Interscript Offensive
To: Lampson, Horning, Ayers
cc: mitchell

I would like not to meet during the week of April 4-8 on Interscript but the following week, April 11-15.  Is this okay with you three?

Jim M.

*start*
00342 00099 US 
gvMsgID: Horning.pa $ 3#203@24-Mar-83  9:30:24 PST
Categories: InterScript
Date: 24-Mar-83  9:30:14 PST
From: Horning.pa
Subject: Re: Remaining "March" Interscript Offensive
In-reply-to: mitchell's message of 24-Mar-83  9:10:29 PST
To: mitchell.pa
cc: Lampson, Horning, Ayers

Jim,

It's better for me, too.

Jim H.


*start*
00325 00097 US 
gvMsgID: Ayers.PA $ 60#91@25-Mar-83  9:08:37 PST
Categories: InterScript
Date: 25 Mar 83 09:08:43 PST (Friday)
From: Ayers.PA
Subject: Re: Remaining "March" Interscript Offensive
In-reply-to: mitchell's message of 24-Mar-83  9:10:29 PST
To: mitchell

As indicated orally, either week is fine with me.
*start*
00891 00097 US 
gvMsgID: Ayers.PA $ 60#91@26-Mar-83 18:26:37 PST
Categories: InterScript
Date: 26 Mar 83 18:26:39 PST (Saturday)
From: Ayers.PA
Subject: Baselines: Knuth vs Interscript
To: Lampson, Horning, Mitchell
cc: Ayers

Consider a column of text lines. Suppose every character is ten points high. And suppose that there is a lot of line leading -- much inter-line glue. 

But in the first five lines, every character has its baseline in the middle (five points above and five below) while in the rest of the lines, the baseline is near the bottom (eight points above and two below).

Knuth will set the baselines ten+glue points apart, with the visual result that the ink in lines five and six is closer together than elsewhere, since that junction has facing five point descenders and eight point ascenders.

Interscript cannot achive this effect.  Is that good or bad?

Bob
*start*
00995 00099 US 
gvMsgID: Lampson.PA $ 31#14@28-Mar-83  9:57:48 PST
Categories: InterScript
Date: 28 March 1983 12:57 pm EST (Monday)
From: Lampson.PA
Subject: Re: Baselines: Knuth vs Interscript
In-reply-to: Ayers' message of 26 Mar 83 18:26:39 PST (Saturday)
To: Ayers
cc: Lampson, Horning, Mitchell

I think it's bad. If I understand the situation correctly, to achieve this effect the
inter-line glue must control the distance between the origins of the lineboxes,
not between the edges. This seems like a good option to have.

I am considering yet another scheduling option, to cut down on the amount of
flying I have to do. This is to come out on Wednesday, April 13, and work the
rest of that week (April 13-15) and all the following week (April 18-22). The
next week (April 25-29) is the Pajaro meeting. This would give us 7 or 7.5
regular working days, with the possibility of writing or meeting on either or
both weekends. But it does delay things somewhat. What do you think?

*start*
02669 00099 US 
gvMsgID: Horning.pa $ 3#203@28-Mar-83 10:06:39 PST
Categories: InterScript
Date: 28-Mar-83 10:05:31 PST
From: Horning.pa
Subject: Document Interchange Query
To: Ayers, Mitchell, Lampson

[This is a former student from Toronto.]

-------------------------------------
Received: from UDEL-RELAY.ARPA by PARC-MAXC.ARPA; 26 MAR 83 03:53:11 PST
Return-path: <@udel-relay.ARPA:Barnard.QUCIS@QuCIS>
Date: 25 Mar 83 16:25:07 EST (Fri)
From: Barnard@QUCIS.ARPA
Return-Path: <Barnard.QUCIS@QuCIS>
Subject:  Document Interchange
To: horning.PA
Via:  QuCIS; 26 Mar 83 3:20-EST

We are working on an integrated way to move documents between VAXen running
Unix or VMS, and IBM systems running VM/CMS.  We have seen IBM material on
their Document Interchange Arcitecture (DIA).  Is anyone there working on
such things?  If so, can you put us in contact, or suggest what we could
read?  Do you know of any other related work elsewhere?


------------------------------------------------------------
Date: 28-Mar-83 10:02:51 PST
From: Horning.pa
Subject: Re: Document Interchange
In-reply-to: Barnard@QUCIS.arpa's message of 25 Mar 83 16:25:07 EST (Fri)
To: Barnard@QUCIS.arpa
cc: horning.pa

Dave,

Not only are people here working on this problem, I am one of them!

Unfortunately, because of potential implications for the product line, we do not yet have clearance to publish anything. We feel that our work is significantly in advance of anything IBM has published, but of course we don't know what IBM has up their sleeve.

Our statement of goals was adopted almost literally by ANSI X3V6. We claim that the interchange standard must have the property that any reasonable editor should be able to record both values and structures of both content and form in an INFORMATION LOSSLESS manner (i.e., externalizing a document and then internalizing it should appear to the user as a no-op). We also claim that even a low-capability editor should be able to internalize the interchange form, edit the parts that it "understands" (e.g., figure captions), and then externalize, without disturbing parts that it doesn't "understand" (e.g., bar charts or spline curves). We think we see how to achieve these goals in a very simple, general manner that subsumes TEX, Scribe, Star, Tioga, Bravo, and GML. But we haven't finished writing it up, even for internal consumption.

Jim H.

PS I assume that you are familiar with the ACM Text Manipulation conference proceedings (SIGPLAN Notices, June 1981). Have you talked to the people at Stanford (Brian Reid), CMU (start from Mary Shaw), and MIT about this?
------------------------------------------------------------
*start*
01265 00100 US 
gvMsgID: mitchell.pa $ 3#171@28-Mar-83 12:09:57 PST
Categories: InterScript
Date: 28-Mar-83 12:09:44 PST
From: mitchell.pa
Subject: Re: Baselines: Knuth vs Interscript
In-reply-to: Lampson's message of 28 March 1983 12:57 pm EST (Monday)
To: Lampson.pa
cc: Ayers, Horning, Mitchell

Butler,

Re: Scheduling,

I like the idea of having 7~7.5 working days rather than five because I can't get rid of the niggling feeling that our Interscript plate still has a fair bit on it to be consumed.  I vote for April 13-15 plus April 18-22.

Re: Baselines: Knuth vs Interscript

Having the inter-line glue control the distance between the origins of the lineboxes, not between the edges seems like a reasonable way to get TEX's effect, but to keep the number of options down, it would be nice if the measure were ALWAYS from a span's origin.  For fixed spans this is clearly no problem (the measures just change in an obvious way).  For spans with DontCares, however, I don't see how to do it (since to get "normal" n-point leading, the glue measure for the high part of the span would have to be expressed as something like DontCare+n, yuch!  So, one more option on a measure, whether it is relative to the (high or low) end or the origin.

Jim M.


*start*
01097 00097 US 
gvMsgID: Ayers.PA $ 60#91@28-Mar-83 13:29:44 PST
Categories: InterScript
Date: 28 Mar 83 13:30:05 PST (Monday)
From: Ayers.PA
Subject: Re: Baselines and "one more option"
In-reply-to: mitchell's message of 28-Mar-83 12:09:44 PST
To: mitchell
cc: Lampson, Ayers, Horning

    "So, one more option on a measure, whether it is relative to the 
     (high or low) end or the origin."
     
I interpret your suggestion as adding a boolean (or atom) that says whether my distance-to-above-sibling is measured from my top or my baseline.

If I say "measure from my baseline" then I've got both my distance-to-above-sibling and my height-above-baseline measures potentially fighting it out with another pair of measures that extend down from my sibling.

It was hard enough to understand when we had two measures fighting it out in that gap; this could produce four.

Bob

PS: In trying to write up layout and penalties, I've already (been forced to) introduce an atom which says whether the inter-sibling measures add serially (like Star) or add in parallel (about like Tioga).


*start*
01082 00099 US 
gvMsgID: Horning.pa $ 3#203@28-Mar-83 13:52:24 PST
Categories: InterScript
Date: 28-Mar-83 13:51:16 PST
From: Horning.pa
Subject: Re: Baselines and "one more option"
In-reply-to: Ayers' message of 28 Mar 83 13:30:05 PST (Monday)
To: Ayers.pa
cc: mitchell, Lampson, Horning

Bob,

Unless my memory is playing me false, this is EXACTLY the reason that we decided that the f1, f2, f3 decision would be made by the CONTAINER. You recall that the f3 (TEX) variant had to take the containee spans (not just their sizes and/or glues) as parameters, so that it could get at the high part of one and the low part of the other.

It's not exactly pretty that TEX interline glue takes this particular form in our model, but there doesn't seem to be any obvious model in which it's a lot simpler. Knuth's own description of interline glue isn't appreciably simpler.

It does seem important to be able to do at least as well as TEX in this area, which probably means exactly matching TEX, since it's so damn hard to foresee all the consequences of any deviation.

Jim H.

*start*
00611 00099 US 
gvMsgID: Lampson.PA $ 31#14@30-Mar-83 14:50:55 PST
Categories: InterScript
Date: 30 March 1983 5:50 pm EST (Wednesday)
From: Lampson.PA
Subject: Next Interscript meeting
To: Ayers, Horning, Mitchell
cc: Lampson

Alas, I have been unable to find child care for April 14-15. Therefore the only
thing I can propose is the week of the 18th. We can spill over to the following
weekend. The next week is Pajaro, but we could also spill over to the following
week in case of emergency. I have to be back in Philadelphia by Thursday 5
May, however, since I'm leaving for vacation on Saturday.


*start*
04581 00099 US 
gvMsgID: Lampson.PA $ 31#14@30-Mar-83 15:57:36 PST
Categories: InterScript
Date: 30 March 1983 6:57 pm EST (Wednesday)
From: Lampson.PA
Subject: Semantics for pouring
To: Ayers, Horning, Mitchell
cc: Lampson

The following is copied from the board

-------------

Pour[T, RL, G]=T[Gj moldedBy Mk / Mk] (A j, k) j<>k
  (missing requirement to use up G)

Number X over P: tree shaped like X, but with nodes <x, i> or <x, nil>
  (need a program)

i>(RL, X)j: i<j and (Xi.labels cap RL=Xj.labels cap RL or i=0)
		  and (Xk.labels cap RL=Xj.labels cap RL => k<i or k>j)
(i is immediate predecessor of j in some stream)

j<>(T, G, RL)l: (E i, k) i>(T+)j and k>(G+)l and i<>k and G+l satisfies T+j
		 or j=l=0
(j is the node in T that corresponds with l in G in Pour[T, RL, G])

T+=Number(T, lambda x in x.labels cap RL~=empty and MOLD$ in x.tags)
G+=Number(G, lambda x in x.labels cap RL~=empty)

x satisfies y: ~(x=# and y=#) and (x=# or y=# or x=y or
					    (x and y are nodes and 
					     x.tags cup {MOLD$} subset of y.tags and
					     (A a in y.attrs) x.a satisfies y.a) )

x moldedBy y: if x=y or x=# then y
	          else if y=# then x
		  else {x | (A a in y.attrs) a_(x.a moldedBy y.a)) }

R a RE, R- is the set of instances generated by R:
	t in R-: R=R1 R2 and t=t1 t2 and ti in Ri-
	      or R=R1 | R2 and (t in R1- or t in R2-)
	      or R=r1* and (t=empty or (t=t1 t2 and t1 in R1- and t2 in R-)

R++ is the set of best instances generated by R:
	t in R++: t in R- and (At' in R-) P(t')>=P(t)

--------------

The rest is new

NOTATION

R is a regular expression, r an instance, p an instance which is a prefix, g a
galley. 

P is the penalty function.

[] for fence.

Matching
r\\g = r matches g, i.e. 			R\\g = {r in R-: r\\g}
	g can be poured into r

Pouring
r//g = result of the pour,			R//g = {r//g: r in R\\g}
	defined only if r\\g



Matching prefix
r\g = Exists p: rp\\g			R\g = {r in R-: r\g}

Poured prefix
r/g = x suchthat Exists p,y: [ rp\\g 	R/g = {r/g: r in R\g}
	                     and rp//g=xy]
	defined only if r\g


Removing prefix
gp = g with all nodes removed that match nodes of p in p/g.
	defined only if p\g

Facts
	p\g => p\(p/g)
	r\\g-p = pr\\g
	r\g-p = pr\g
	

ACCEPTABLE

R$g = {r in R\g such that

  R=R1 R2 and	All s1 in R1$g, All s2 in R2$(gs1): P((s1 s2)/g) >= P(r/g)
or
  R=R1 [] R2 and	Exists r1, r2: r=r1 r2 and r1 in R1$g and r2 in R2$(gr1)
or
  R=R1 | R2 and	All s in R1$g union R2$g: P(s/g) >= P(r/g)
or
  R=R1* and		All i>0, All si in R1$(gs1...s(i1)): 
								P((s1 ... si)/g) >= P(r/g)
or
  R=Limit(R1, Ta, Tr, C)  and 
		  	  r in S
  --abs. threshold--
    		  and   P(r/g) <= Ta
  --rel. threshold--
    		  and	 Exists i>0, All s in S: [        s in N^i(r)=>P(s/g)>=P(r/g)+Tr
					     and All j<i: s in N^j(r)=>P(s/g)>=P(r/g) ]
  --cutoff--
		  and	 All i<C,   All s in S:          s in N^i(r)=>P(s/g)>=P(r/g)

WHERE S=R1$g, N=Next(S) IN --N^i is N to the ith power

This makes it clear that the effect of Fence is to factor the search, and the effect
of Limit is to limit the search to a smaller set.

Here Next(S) is a function that gives the partial ordering of elements of S. It is
defined as follows:

Next(R$g)(r)={r' in R$g: r' in Next(R)(r)}

where Next is defined on regular expressions as follows:

Next(R)(r)={r' in R-:
  R=R1 R2 and	Exists r1, r1' in R1, r2, r2' in R2: r=r1 r2 and r'=r1' r2' and
							   [r1'=r1 and r2' in Next(R2)(r2)
							 or r2'=r2 and r1' in Next(R1)(r1)]
or
  R=R1 | R2 and	   [r in R1- and r' in Next(R1)(r)] 
			or [r in R2- and r' in Next(R2)(r)]
			or [r' in First(R2) and r in Last(R1)]
or
  R=R1* and		the obvious thing implied by the previous cases

Note that these definitions make the order of search that controls the limit
depend entirely on the regular expression, not on the numbering of elements in
the streams from the galley. The main reason for this is that it isn't clear how
such numbering should interact with the alternatives in the regular expression,
since a single galley prefix can match several instances of the RE. Doing it the
other way avoids this problem, since a single instance of the RE can match at
most one prefix of the galley.

Some examples illustrate how this Next function works.  For a*b*, we get by
successively applying Next:

	empty
	a  b
	aa  ab  bb
	aaa  aab  abb  bbb
	. . .

For a*b*c* we get

	empty
	a  b  c
	aa  ab  ac  bb  bc  bb
	aaa  aab  aac  abb  abc  acc  bbb  bbc  bcc  ccc
	. . .

For (a | b | c) (d | e | f ) we get
	ad
	ae  bd
	af  be  cd
	bf  ce
	cf

So it doesn't grow too fast.
*start*
00560 00100 US 
gvMsgID: mitchell.pa $ 3#171@30-Mar-83 17:27:45 PST
Categories: InterScript
Date: 30-Mar-83 17:27:54 PST
From: mitchell.pa
Subject: Re: Next Interscript meeting
In-reply-to: Lampson's message of 30 March 1983 5:50 pm EST (Wednesday)
To: Lampson.pa
cc: Ayers, Horning, Mitchell

Okay, the 18th it is.   I will keep the weekend of 23-24 April open for meeting.  The following weekend I plan to attend my brother's wedding, leaving 29 April and returning (probably), Wednesday, May 4 after visiting U. of Toronto and U. of Waterloo. 

Jim
*start*
00397 00099 US 
gvMsgID: Horning.pa $ 3#203@30-Mar-83 20:16:15 PST
Categories: InterScript
Date: 30 March 1983 8:15 pm PST (Wednesday)
From: Horning.pa
Subject: Re: Next Interscript meeting
In-reply-to: mitchell's message of 30-Mar-83 17:27:54 PST
To: mitchell
cc: Lampson, Ayers, Horning

I will be in Boston May 2-10. I'm willing to work the weekend of April 23-24
if necessary.

Jim H.
*start*
00522 00099 US 
gvMsgID: Horning.pa $ 3#203@ 4-Apr-83 15:55:08 PST
Categories: InterScript
Date:  4-Apr-83 15:55:16 PST
From: Horning.pa
Subject: Re: Semantics for pouring
In-reply-to: Lampson's message of 30 March 1983 6:57 pm EST (Wednesday)
To: Lampson.pa
cc: Ayers, Horning, Mitchell

Butler,

Received and read once. ("Studied" would be an overstatement.)

I'm not sure I grok the details, and it's disappointing that quite so many details seem to be required, but it has the look of being workable.

Jim H.

*start*
00925 00097 US 
gvMsgID: LAMPSON.PA $ 3#5@ 4-Apr-83 19:49:01 PST
Categories: InterScript
Date:  4 APR 83 19:49 PST
From: LAMPSON.PA
Subject: Re: Semantics for pouring
To:   Horning, Lampson
cc:   Ayers, Mitchell

In response to the message sent   4-Apr-83 15:55:16 PST from Horning.pa

Prettied-up version of the pouring stuff, with a number of details filled in and some explanatory prose added, is on [Ivy]<Lampson>Pouring.press. It also has a proposal for encoding, which should be taken as a suggestion only.

Jim H: I though we were getting off pretty lightly, considering the rather ad-hoc nature of the Limit stuff. It might be cleaner if we could use the g sub i and g super i stuff that was on the board at the end of our last meeting, rather than defining that messy Next function, but I couldn't see how to do it. Also, it might be that on reflection some of the definitions and notation could be elided.

*start*
00854 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 5-Apr-83 14:09:49 PST
Categories: InterScript
Date:  5 Apr 83 14:10:23 PST (Tuesday)
From: Ayers.PA
Subject: Documentation and [Ivy]<Lampson>Pouring.press
To: Lampson, Mitchell, Horning
cc: Ayers

Pouring: I've read it twice and now believe pages two and three.

Encoding: I claim I understand it and like it. I especially like the "parallel sequence"

Documentation: I plan on passing around my current draft "section four" (which has become two sections) early tomorrow. I will give a copy to the CSL secretary to express to Butler. It covers "solid" layout but I've not yet done anything on pouring.

Future: Given Butler's start, I think I can do a good job defining an encoding for the standard. I'm less sure that I can adequately document pouring. So I propose to try the former. Comments?

Bob 
*start*
01078 00097 US 
gvMsgID: Ayers.PA $ 60#91@12-Apr-83 16:52:34 PST
Categories: InterScript
Date: 12 Apr 83 16:52:34 PST (Tuesday)
From: Ayers.PA
Subject: Lampson's "parallel sequence" in the Encoding
To: Lampson, Mitchell, Horning
cc: Ayers

Butler's proposal suggests:

   "There are tokens for encoding a reference to another parallel 
    sequence of bytes:
          REF ab
	  SHORTREF a
    The operand gives the number of bytes to take from the parallel 
    sequence.  The meaning is exactly as though ..."
    
This proposal implies that the parallel sequence is "used up" by the REFs, and so we only have to supply lengths.

Alternatively, we cold supply both a location and a length in the parallel sequence. This increases the size of the REF, but allows:

    1. Re-use of the same substring (perhaps bad).
    2. Easy "skip over" of bytes that were convenient to copy into.
       the sequence, but are not relevent to Interscript, e.g. look info.
    3. The ordering of the sequence to be different than the ordering 
       of the script.
       
Comments?
*start*
00430 00097 US 
gvMsgID: LAMPSON.PA $ 3#5@12-Apr-83 17:05:49 PST
Categories: InterScript
Date: 12 APR 83 17:06 PST
From: LAMPSON.PA
Subject: Re: Lampson's "parallel sequence" in the Encoding
To:   Ayers, Mitchell, Horning
cc:   LAMPSON

In response to the message sent  12 Apr 83 16:52:34 PST (Tuesday) from Ayers.PA


I think it would be better to have a POS ab (and perhaps LONGPOS abc) token which resets the position.
*start*
00971 00097 US 
gvMsgID: Ayers.PA $ 60#91@13-Apr-83 10:14:01 PST
Categories: InterScript
Date: 13 Apr 83 10:14:05 PST (Wednesday)
From: Ayers.PA
Subject: On Lampson's REF to another parallel sequence of bytes
To: Lampson, Mitchell, Horning
cc: Ayers

Butler suggests [REF and SHORTREF] "The meaning is exactly as though the referenced bytes had appeared instead of the REF."

This means that an editor which wants to put the text in the "parallel sequence" (e.g. Tioga) has to put fragments of the form

    STRINGab now is the time  STRINGcd for all good men  STRINGef to come to
    
over in the parallel encoding, and cannot just put raw text over there. Further, the editor must fragment the parallel text according to the script's needs -- namely a new fragment at every change in looks.

I claim that this is unfortunate and that what we need is a STRINGREF (?) which has its ab in the script and takes just the characters from the parallel sequence.

Bob 
*start*
00469 00099 US 
gvMsgID: Lampson.PA $ 31#14@14-Apr-83  6:17:59 PST
Categories: InterScript
Date: 14 April 1983 9:19 am EST (Thursday)
From: Lampson.PA
Subject: Re: On Lampson's REF to another parallel sequence of bytes
In-reply-to: Ayers' message of 13 Apr 83 10:14:05 PST (Wednesday)
To: Ayers
cc: Lampson, Mitchell, Horning

Yes, I agree that we also need STRINGREF; that was an oversight. I did make the
TINYSREF a string ref, but we need regular ones too.

*start*
01121 00099 US 
gvMsgID: Horning.pa $ 3#203@14-Apr-83 15:31:46 PST
Categories: InterScript
Date: 14-Apr-83 15:31:50 PST
From: Horning.pa
Subject: Chap. 4
To: Ayers
cc: Mitchell, Lampson, Horning

Bob,

I've completed a pass through the 5 April draft, without finding any show-stoppers. In fact, most of my marks relate to low-level issues of presentation that you would probably just as soon deal with as discuss next week. The question is: Should I try to get the marked-up copy to you before next week? (Probably useful only if you are planning another pass over the document between now and Monday.)

Slightly higher-level issues:

"We" vs. "Interscript 83"?

End of 4.2: Need list of tags to be defined in this chapter.

Do we want to stick with the term "pour" permanently? "Layout" would be better, except that we make such heavy use of it as a noun.

Should FILL$ and TOGETHER$ specify the "level" they refer to (e.g., page or column)?

Figure 4.5.1 doesn't reflect the new constructs and terminology yet.

Can't the fillInRule just be a quoted expression?

Streams just kind of sneak in in 4.6.2

Jim H.

*start*
00434 00097 US 
gvMsgID: Ayers.PA $ 60#91@14-Apr-83 18:15:18 PST
Categories: InterScript
Date: 14 Apr 83 18:15:16 PST (Thursday)
From: Ayers.PA
Subject: Chap 4 & 5 ...
To: Horning, Mitchell, Lampson
cc: Ayers

I don't plan on another chapter 4&5 pass between now and Monday unless I get carried away.

I do plan on having an encoding chapter available Monday.

And now its about time to start work on my income taxes ...

Bob
*start*
00601 00100 US 
gvMsgID: mitchell.pa $ 3#171@15-Apr-83 15:34:15 PST
Categories: InterScript
Date: 15-Apr-83 15:34:17 PST
From: mitchell.pa
Subject: Updated syntax and semantics
To: Ayers, Horning, Lampson
cc: mitchell

There is an updated, complete version of the Interscript language syntax and semantics available as [indigo]<interscript>DraftStd>interscript-language.press.

It claims to give semantics for every language construct and includes error conditions to detect semantically invalid scripts.  I am interested in any holes you find in this claim.

See you all Monday at 9:30.

Jim
*start*
00515 00097 US 
gvMsgID: Ayers.PA $ 60#91@18-Apr-83 17:20:10 PST
Categories: InterScript
Date: 18 Apr 83 17:20:10 PST (Monday)
From: Ayers.PA
Subject: On Boldness
To: Lampson, Mitchell, Horning
cc: Ayers

I today received my new copy of ITC's U&lc.  It contains an editorial which discusses how an individual artist might submit a typeface to ITC:

     "... Since ITC usually markets typefaces as full families -- four
      roman weights with corresponding italics -- ..."
      
Bold: TYPE = {0,1,2,3} ?
*start*
00776 00099 US 
gvMsgID: Horning.pa $ 3#203@18-Apr-83 18:26:59 PST
Categories: InterScript
Date: 18-Apr-83 18:26:58 PST
From: Horning.pa
Subject: Re: On Boldness
In-reply-to: Ayers' message of 18 Apr 83 17:20:10 PST (Monday)
To: Ayers.pa
cc: Lampson, Mitchell, Horning

Bob,

And the other font distributors?

Besides, this is really a red herring. We are interested in the information that an EDITOR would want to preserve orthogonally to family name, in the same way it would treat size, italic, or underline. I don't know of any editors that give me four flavors of boldness, and I'm not sure that it would be a good idea, since two out of the four should probably be selected in the (electronic or hardcopy) stylesheet for any given region of a document.

Jim H.

*start*
03884 00099 US 
gvMsgID: Lampson.PA $ 3#217@20-Apr-83 20:03:56 PST
Categories: InterScript
Date: 20 April 1983 8:03 pm PST (Wednesday)
From: Lampson.PA
Subject: Solid layout
To: Ayers, Horning, Mitchell
cc: Lampson

To: Ayers, Horning, Mitchell

TERMINOLOGY
----------------

A fixed measure is one one with o=u=0



TYPES
----------

BOX$			x, y: Span
			rotation: [0..3]

SPAN$		l, h, cl, ch, sl, sh: Measure

LAYOUTINSIDES$	how: XYLayout	-- Subtag of BOX

XYLAYOUT$	x, y: HowToLayout

HOWTOLAYOUT$	method: {fixed, up, down, onOrigins}
			sibGlueF: {parallel, serial}

MEASURE$		e, o, u: Distance

Measure:		MEASURE$
		     |	bound
		     |	synth



FUNCTIONS
------------

-- How to index the content boxes of a box

If B: Box, let B.n be the number of content boxes1,
and B.c: array [0..B.n] of box = such that B.ci is B's ith content box, i in [0..B.n].
Let B.b be B.c, but reversed if layout=down
	B.bi=if layout=down then B.c(B.ni) else B.ci	for i in [0..n]


-- Replace all synth or bound measures with the measure derived from the
    contents

GetAllMeasures:	[B: LayoutInsides, xy: SpanName]
	   >		[B': LayoutInsides] =
	for lh in MeasureName do B=GetMeasure[B, xy, lh]
	B'=B

GetMeasure:	[B: LayoutInsides, xy: SpanName, lh: MeasureName]
	   >	[B': LayoutInsides] =
	let m: Measure=B.xy.lh
	let method: LayoutMethod=B.how.xy.method
	--Compute the measures of B's contents
	let b: array [0..B.n] of LayoutInsides=
		for i in [0..B.n] bi=GetMeasure[B.bi, xy, lh]
	let bm: array [0..B.n] of Measure=
		for i in [0..B.n] bmi=bi.xy.lh
	let m': Measure=
	   if m is a MEASURE$ then m
	   else if method=fixed then error
	   else if lh is cl, ch, sl or sh then {MEASURE$ 0 0 0}
	   else if m=synth then CombineMeasures[bm, method, lh]
	   else if m=bound then {MEASURE$ 
				      CombineMeasures[bm, method, lh].e 0 0}
	B'=B except 
	   B'.xy.lh_m'
	   for i in [0..B.n]
		B'.bi=bi

CombineMeasures:	[bm: array [0..B.n] of Measure, 
			 method: LayoutMethod, lh: MeasureName]
	   >		[m: Measure] =
	if method=onOrigins then Parallel(bm)
	else if lh is l, then bm0
	else if lh is h, then Sum(Decompose(bm)bm0)
	else bug

-- Take a box after GetAllMeasures and fix all the measures

FixMeasures:  [B: LayoutInsides, xy: SpanName]
	   >	 [B': LayoutInsides] =
	let s=B.xy
	let how=B.how.xy
	if how.method=fixed then B'=B
	else if how.method=up or how.method=down then
		let spaceAvailable=B.xy.l.e+B.xy.h.e
		let b: array [0..B.n] of Span=
		   for i in [0..B.n] bi=B.bi.xy
		let a: array [0..3*B.n+3] of Measure=Decompose[b, how.sibGlueF]
		let d: array [0..3*B.n+3] of Dim=SetGlue[a, spaceAvailable]
		let b': array [0..B.n] of Span=Recompose[b, d]
		B'=B except for i in [0..B.n] 
			B'.bi=Fix[{B.bi | xy_b'i}, xy]
	elseif how.method=onOrigins then
		B'=B except for i in [0..B.n] 
			let cl=B.xy.l-B.bi.xy.l
			if cl<0 or B.xy.h-B.bi.xy.h<0 then error
			B'.bi={B.bi | xy.cl_cl}


-- Functions to do the glue setting calculations

Decompose:	[b: array [0..n] of Span, 
	     	 GlueF: proc[Span, Span]>[Measure] ]
	   >	[a: array [0..3n+3]  of Measure] where
	a0=b0.cl
	a(3i+1)=bi.l			for i in [0..n]
	a(3i+2)=bi.h			for i in [0..n]
	a(3i)=GlueF[b(i-1), b(i)]	for i in [1..n]
	a(3i+3)=bn.ch


SetGlue:	[b: array [0..n] of Measure, s: Distance]
	   >	[a: array [0..3n+3]  of Distance] where
	let m=Sum[b];
	let t=sm.e
	let f=if t>0 then t/(m.om.e) else t/(m.em.u)
	ai=bi.e+f*(if f>0 then (bi.obi.e) else (bi.ebi.u))
Note that s=Sum[a]


Recompose:	[b: array [0..n] of Span, 
		 a: array [0..3n+3]  of Distance] 
	   >	[b': array [0..n]  of Span] =
	let b'(1).ch={MEASURE$ 0 0 0}
	let s=Sum(a)
	b'=b except for i in [0..n]
		b'i.sl=b'i.sh={MEASURE$ 0 0 0}
		b'i.cl={MEASURE$ b'(i1).ch+d(3i) 0 0}
		b'i.l={MEASURE$ d(3i+1) 0 0}
		b'i.h={MEASURE$ d(3i+2) 0 0}
		b'i.ch={MEASURE$ s(b'i.cl+b'i.l+b'i.h).e 0 0}
Note that b'n.ch=a(3n+3), because s=Sum[a]

	
*start*
04296 00099 US 
gvMsgID: Lampson.PA $ 3#217@22-Apr-83 23:34:45 PST
Categories: InterScript
Date: 22 April 1983 11:34 pm PST (Friday)
From: Lampson.PA
Subject: Solid layout
To: Ayers, Horning, Mitchell
cc: Lampson



TYPES
----------

BOX$			x, y: Span
			rotation: [0..3]

SpanName: type={x, y}

SPAN$		l, h, cl, ch, sl, sh: Measure 

MeasureName: type={l, h, cl, ch, sl, sh}

LAYOUTINSIDES$	how: XYLayout	-- Subtag of BOX

XYLAYOUT$	x, y: HowToLayout

HOWTOLAYOUT$	method: LayoutMethod
			sibGlueF: proc[Span, Span]->[Measure] --parallel, serial, Tex

LayoutMethod: type={fixed, up, down, onOrigins}

MEASURE$		e, o, u: Distance

Measure:		MEASURE$
		     |	synth



TERMINOLOGY
----------------

A fixed measure is one with o=u=0


FUNCTIONS
------------

If B: Box, let B.n be the number of content boxes1,


WHAT ABOUT ROTATION

-- Replace all synth or bound measures with the measure derived from the
    contents

GetAllMeasures:	[B: LayoutInsides, xy: SpanName]
	   >		[B': LayoutInsides] =
	for lh in MeasureName do B=GetMeasure[B, xy, lh]
	B'=B

GetMeasure:	[B: LayoutInsides, xy: SpanName, lh: MeasureName]
	   >	[B': LayoutInsides] =
	let m: Measure=B.xy.lh
	let how: LayoutMethod=B.how.xy
--Compute the measures of B's contents, reversing the order if method=down
	let b: array [0..B.n] of Box=for i in [0..B.n]
		let bb=B!(Reverse[i, B, xy])
		b!i=	if LAYOUTINSIDES in bb.tags then GetMeasure[bb, xy, lh]
			else if bb.xy.lh#synth then bb
			else error
	let m': Measure=
	   if m#synth then m
	   else if how.method=fixed then error
	   else if lh is cl, ch, sl or sh then m
	   else -- m=synth, method#fixed, lh=l or h 
		if how.method=onOrigins then Parallel(bm)
			where bm: array [0..B.n] of Measure= 
			  for i in [0..B.n] bm!i=
				if lh=l then b!i.xy.l+b!i.xy.cl
				else          b!i.xy.h+b!i.xy.ch
		else -- how.method=up or how.method=down
		   if lh=l then b!0.xy.lh
		   else --lh=h-- Sum(Decompose(bs, how.sibGlueF)b!0.xy.lh)
			where bs: array [0..B.n] of Span=for i in [0..B.n] bs!i=b!i.xy
		   
	B'=B except 
	   B'.xy.lh_m'
	   for i in [0..B.n] B'!i=b!(Reverse[i, B, xy])

-- Takes a box after GetAllMeasures and fixes all the measures
FixMeasures:	[B: LayoutInsides, xy: SpanName]
	   >	[B': LayoutInsides] =
	let s=B.xy
	let how=B.how.xy
	if how.method=fixed then 
		B'=B except for i in [0..B.n] B'!i=FixMeasures[B!i, xy]
	elseif how.method=onOrigins then
		B'=B except for i in [0..B.n] 
			let cl=B.xy.l.e-B!i.xy.l.e
		--	if cl<0 or B.xy.h.e-B!i.xy.h.e<0 then stickout
			B'!i=FixMeasures[{B!i | xy.cl_MkFixedMeasure[cl]}, xy]
	else if how.method=up or how.method=down then
		let spaceAvailable=B.xy.l.e+B.xy.h.e
		let b: array [0..B.n] of Span=for i in [0..B.n] 
			b!i=B!(Reverse[i, B, xy]).xy
		let a: array [0..3*B.n+3] of Measure=Decompose[b, how.sibGlueF]
		let d: array [0..3*B.n+3] of Dim=SetGlue[a, spaceAvailable]
		let b': array [0..B.n] of Span=Recompose[b, d]
		B'=B except for i in [0..B.n] 
			B'!i=FixMeasures[ {B!i | xy_b'!(Reverse[i, B, xy])}, xy]

-- Reverse the order of content indexing if layout method=down
Reverse:	[i: Integer, B: LayoutInsides, xy: SpanName, xy]->[Integer]=
	if B.how.xy.method=down then B.n-i else i


-- Functions to do the glue setting calculations

Decompose:	[b: array [0..n] of Span, 
	     	 GlueF: proc[Span, Span]>[Measure] ]
	   >	[a: array [0..3n+3]  of Measure] where
	a!0=b!0.cl
	a!(3i+1)=b!i.l			for i in [0..n]
	a!(3i+2)=b!i.h		for i in [0..n]
	a!(3i)=GlueF[b!(i-1), b!(i)]	for i in [1..n]
	a!(3i+3)=b!n.ch


-- TAB STUFF GOES IN HERE SOMEWHERE

SetGlue:	[b: array [0..n] of Measure, s: Distance]
	   >	[d: array [0..3n+3]  of Distance] where
	let m: Measure=Sum[b];
	let delta: Distance=sm.e
	let f=if delta>0 then delta/(m.om.e) else delta/(m.em.u)
	for i in [0..n]
		d!i=b!i.e+f*(if f>0 then (b!i.ob!i.e) else (b!i.eb!i.u))
Note that s=Sum[d]


Recompose:	[b: array [0..n] of Span, 
		 d: array [0..3n+3]  of Distance] 
	   >	[b': array [0..n]  of Span] =
	let s=Sum(d)
	b'=b except for i in [1..n]
		b'!i.cl=FixedMeasure[if i=0 then d!0 else
					b'!(i1).cl+d!(3i2)+d!(3i1)+d!(3i)]
		b'!i.l=FixedMeasure[d!(3i+1)]
		b'!i.h=FixedMeasure[d!(3i+2)]
Note that ch, sl and sh are meaningless in the recomposed spans

FixedMeasure: [d: Distance]>[m: Measure]={MEASURE$ d 0 0}

	
*start*
04984 00099 US 
gvMsgID: Lampson.PA $ 3#217@24-Apr-83 19:37:57 PDT
Categories: InterScript
Date: 24 April 1983 7:37 pm PDT (Sunday)
From: Lampson.PA
Subject: Remote stuff
To: Ayers, Horning, Mitchell
cc: Lampson

To: Ayers, Horning, Mitchell

-----------
Here are the declarations for TAG and TYPE, together with some useful auxiliary
stuff.

I changed TYPE slightly, adding explicit code and tags attributes. The predicate
that gets tested is 
	(code=TypeCode.Any or code=TYPECODE(A)) AND
	(if code.TypeCode.Node then tags SUBSETOF TAGS(A) else 1) AND
	predicate

TAG%_{TAG$
	attributes_{
		attributes_{TYPE$ 
			predicate_--each binding is to a Type--????
			default_{}}
		requiredTags_AtomList
		contentType_{Type | default_Any}
		nodeInvariant_{Predicate | default_'1'}
		hasMoreInv_{Bool | default_0}
		reducesTo_{Any | 
			predicate_'A=NIL OR TYPECODE(A)=TypeCode.Quoted'}
	contentType_None
-- The rest of these could be defaulted, but are here for clarity
	requiredTags_{}
	nodeInvariant_'1'
	hasMoreInv_0
	reducesTo_NIL}

TYPE%_{TAG$
	attributes_{
		code_{TypeCode | default_TypeCode.Node}
		tags_AtomList
		predicate_{Predicate | default_'1'}
		default_{Any | default_NIL --Minimal automatic default--} }
	contentType_None}


-- Notation
0..7 --Short for {TYPE$ code_TypeCode.Int predicate_'A>=0 AND A<=7'}}

ONEOF {N0 N1 ... Nk} --Short for {TYPE$
	code_TypeCode.Int predicate_'A>=0 AND A<=k'
	N0%_0 N1%_1 ... Nk%_k }


TypeCode=ONEOF {Atom Int Vnode Num Quoted Ind Any}  

Bool%_0..1

Atom%_{TYPE$ code_TypeCode.Atom}
ATOMLIST%_{TAG$ contentType_Atom}
AtomList%_{TYPE$ tags_{ATOMLIST} default_{}}

Any%_{TYPE$ code_TypeCode.Any}
None%_{TYPE$ predicate_'0'}
Predicate%_{TYPE$ code_TypeCode.Quoted}

Type%_{TYPE$ tags_{TYPE} default_Any}
	
-------------
Remote and running stuff

GETV%_{TAG$ 
	attributes_{how_ONEOF{RUNNING REMOTE} arg_Atom val_Any
			 inc_Number} }
SHOW%_{TAG$ 
	attributes_???}
GET%_{TAG$ 
	attributes_???}


{TEXT$
	GETV$	how_RUNNING	arg_FigNum		val_3  inc_1
			how_REMOTE	arg_ExampleFig	val_3
	SHOW$	pic_<ZZ9>
	<3> }

{TEXT$
	GET$	from_ExampleFig
	<3> }

GETV RUNNING sets the val to inc^ + the val of previous GETV RUNNING
with the same arg, if there is one. Otherwise it leaves it unchanged.

GETV REMOTE sets the val to the val of the node labeled arg^

SHOW takes val^, converts it to a string using pic^, and replaces the content
with the result.

GET replaces the content with the content of the node labeled from^.


Note that only SHOW is guaranteed to produce a string. However, the presence of
TEXT$ means that the content had better be a string, otherwise its invariant isn't
satisfied.

Example:
{CAPTION$ 
	{TEXT$ <Figure > }
	{TEXT$ 	GETV$ how_RUNNING arg_FigNum inc_1 val_3
			SHOW$ pic_<ZZ9>
			<3>
			ExampleFig: }
	{TEXT$ <: Example>} }

{TEXT$ <See figure >} {TEXT$ GET$ from_ExampleFig}
{TEXT$ <, in which .....>}


To do Star-style fillin rules, in which the content of remote fields is retrieved
and used in a "Mesa expression", you write
{TEXT$ STARFIELD$ 	args_{	x%^{GET$ from_XField} 
						y%^{GET$ from_YField}
				how_<string for CUSP expression> 
	<123> }
if <123> was the value computed last time.


---------------

For page headings we introduce a new feature of pouring, called VACUUM$.
This node is just like a MOLD$, except that v matches, and is replaced in the
pour by 
	w moldedBy v, 
	   where w=x.sources!i 
		where x=Parent^j(Neighbor)
such that j is the smallest integer such that x is tagged VACSOURCE and i is the
smallest integer such that w satisfies v.
	where Neighbor is gk .......


t=.... 	{red MOLD$ LINE$} 	--3
	{red VACUUM$ secH_# which_prev|succ} 
	{red MOLD$ LINE$}....	--4

g={CHAP$ chHead_<Chap 3>
	{SEC$ secHead_<Sec 3.1>
		{...} ... {red LINE$ xxx --3--} ... }
	{SEC$ secHead_<Sec 3.2>
		{...} ... {red LINE$ yyy --4--} ... }
   }

yields
	{red LINE$ xxx --3--} {red  secH_<Sec 3.1>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 3 as neighbor
	{red LINE$ xxx --3--} {red  secH_<Sec 3.2>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 4 as neighbor


---------

Labels: 
	x:
is short for
	labels_{labels | x}
any you had better put
	l^|
at the start of the node, where
	l_{LABEL$ labels_{}}

----------
Pouring streams

Stream coloring: MOLD$ and GALLEY$ have stream as a ra, and you bind an
atom to it.

{POUR$ template_{RE$ ...} galleyContent} results in 
{CAST$ resultOfPourContent rem_{remainderOfGalley}}

----------

Togetherness

{... TOG$ penalties_{{weight_number level_atom} ...} which_atom ...}
means that any pair of TOG$ nodes with the same which^ should be kept
together.

In a value (node) w, for each pair of nodes <x, y> with  TOG$ and the same
which^, we compute a penalty
	P(w, x, y)=
	  Sum over all <weight, level> pairs in x.penalties union y.penalties
		weight*|Father(w', x).number-Father(w', y).number|
			where w'=Number(w, lambda x in level in x.labels)
			and Father(w, x) is the father of x in the tree w

-------------
*start*
05593 00099 US 
gvMsgID: Lampson.PA $ 3#217@25-Apr-83  9:44:01 PDT
Categories: InterScript
Date: 25 April 1983 9:43 am PDT (Monday)
From: Lampson.PA
Subject: Remote stuff
To: Ayers, Horning, Mitchell
cc: Lampson

To: Ayers, Horning, Mitchell

-----------
Here are the declarations for TAG and TYPE, together with some useful auxiliary
stuff.

I changed TYPE slightly, adding explicit code and tags attributes. The predicate
that gets tested is 
	(code=TypeCode.Any or code=TYPECODE(A)) AND
	(if code=TypeCode.Node then {t_REVEAL(A) tags SUBSETOF t.tags else 1)
AND
	predicate

TAG%_{TAG$
	attributes_{
		attributes_{TYPE$ 
		   predicate_'HASTYPE(TypeBindingsList, REVEAL(A).bindings)'
		   default_{}}
		requiredTags_AtomList
		contentType_{Type | default_Any}
		nodeInvariant_{Predicate | default_'1'}
		hasMoreInv_{Bool | default_0}
		reducesTo_{Any | 
			predicate_'A=NIL OR TYPECODE(A)=TypeCode.Quoted'}
	contentType_None
-- The rest of these could be defaulted, but are here for clarity
	requiredTags_{}
	nodeInvariant_'1'
	hasMoreInv_0
	reducesTo_NIL}

TYPE%_{TAG$
	attributes_{
		code_{TypeCode | default_TypeCode.Node}
		tags_AtomList
		predicate_{Predicate | default_'1'}
		default_{Any | default_NIL --Minimal automatic default--} }
	contentType_None}


-- Auxiliary stuff for TypeBindingsList
TypeBindingsList%_{TYPE$ tags_{TB}}
TB%_{TAG$ contentType_{TYPE$ predicate_'HasType(Type, A!1)'}}

-- New primitives for writing predicates
REVEAL: [n: node]->node={content_VItems(n), tags_Tags(n),
				 bindings_bindings(n)}
TYPECODE: Any->TypeCode
SUBSETOF: [AtomList, AtomList]->Bool
AND, OR, NOT: [Bool, Bool]->Bool
HASTYPE: [Type, Value]->Bool

-- Notation
0..7 --Short for {TYPE$ code_TypeCode.Int predicate_'A>=0 AND A<=7'}}

ONEOF {N0 N1 ... Nk} --Short for {TYPE$
	code_TypeCode.Int predicate_'A>=0 AND A<=k'
	N0%_0 N1%_1 ... Nk%_k }


TypeCode=ONEOF {Atom Int Vnode Num String Quoted Ind Any}  

Bool%_0..1

Atom%_{TYPE$ code_TypeCode.Atom default_0 --no default--}
ATOMLIST%_{TAG$ contentType_Atom}
AtomList%_{TYPE$ tags_{ATOMLIST} default_{}}

Any%_{TYPE$ code_TypeCode.Any}
None%_{TYPE$ predicate_'0'}	--Useful for forbidding content
Predicate%_{TYPE$ code_TypeCode.Quoted}

Type%_{TYPE$ tags_{TYPE} default_Any}
String%_{TYPE$ code_TypeCode.String}
Number%_{TYPE$ code_TypeCode.Number}
	
-------------
Remote and running stuff

GETV%_{TAG$ 
	attributes_{how_ONEOF{RUNNING REMOTE} arg_Atom val_Any
			 inc_Number} }
SHOW%_{TAG$ 
	attributes_{pic_String val_Any}
GET%_{TAG$ 
	attributes_from_Atom}


Sample usage

{TEXT$
	GETV$	how_RUNNING	arg_FigNum		val_3  inc_1
			how_REMOTE	arg_ExampleFig	val_3
	SHOW$	pic_<ZZ9>
	<3> }

{TEXT$
	GET$	from_ExampleFig
	<3> }

GETV RUNNING sets the val to inc^ + the val of previous GETV RUNNING
with the same arg, if there is one. Otherwise it leaves it unchanged.

GETV REMOTE sets the val to the val of the node labeled arg^

SHOW takes val^, converts it to a string using pic^, and replaces the content
with the result.

GET replaces the content with the content of the node labeled from^.


Note that only SHOW is guaranteed to produce a string. However, the presence of
TEXT$ in the examples means that the content had better be a string, otherwise
its invariant isn't
satisfied.

Example:
{CAPTION$ 
	{TEXT$ <Figure > }
	{TEXT$ 	GETV$ how_RUNNING arg_FigNum inc_1 val_3
			SHOW$ pic_<ZZ9>
			<3>
			ExampleFig: }
	{TEXT$ <: Example>} }

{TEXT$ <See figure >} {TEXT$ GET$ from_ExampleFig}
{TEXT$ <, in which .....>}


To do Star-style fillin rules, in which the content of remote fields is retrieved
and used in a "Mesa expression", you write
{TEXT$ STARFIELD$ 	args_{	x%^{GET$ from_XField} 
						y%^{GET$ from_YField}
				how_<string for CUSP expression> 
	<123> }
if <123> was the value computed last time.


---------------

For page headings we introduce a new feature of pouring, called VACUUM$.
This node is just like a MOLD$, except that v matches, and is replaced in the
pour by 
	w moldedBy v, 
	   where w=x.sources!i 
		where x=Parent^j(Neighbor)
such that j is the smallest integer such that x is tagged VACSOURCE and i is the
smallest integer such that w satisfies v.
	where Neighbor is gk .......


t=.... 	{red MOLD$ LINE$} 	--3
	{red VACUUM$ secH_# which_prev|succ} 
	{red MOLD$ LINE$}....	--4

g={CHAP$ chHead_<Chap 3>
	{SEC$ secHead_<Sec 3.1>
		{...} ... {red LINE$ xxx --3--} ... }
	{SEC$ secHead_<Sec 3.2>
		{...} ... {red LINE$ yyy --4--} ... }
   }

yields
	{red LINE$ xxx --3--} {red  secH_<Sec 3.1>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 3 as neighbor
	{red LINE$ xxx --3--} {red  secH_<Sec 3.2>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 4 as neighbor


---------

Labels: 
	x:
is short for
	labels_{labels | x}
and you had better put
	l^|
at the start of the node, where
	l_{LABEL$ labels_{}}

----------
Pouring streams

Stream coloring: MOLD$ and GALLEY$ have stream as a ra, and you bind an
atom to it.

{POUR$ template_{RE$ ...} galleyContent} results in 
{CAST$ resultOfPourContent rem_{remainderOfGalley}}

----------

Togetherness

{... TOG$ penalties_{{weight_number level_atom} ...} which_atom ...}
means that any pair of TOG$ nodes with the same which^ should be kept
together.

In a value (node) w, for each pair of nodes <x, y> with  TOG$ and the same
which^, we compute a penalty
	P(w, x, y)=
	  Sum over all <weight, level> pairs in x.penalties union y.penalties
		weight*|Father(w', x).number-Father(w', y).number|
			where w'=Number(w, lambda x in level in x.labels)
			and Father(w, x) is the father of x in the tree w

-------------
*start*
06001 00099 US 
gvMsgID: Lampson.PA $ 3#217@25-Apr-83 11:17:41 PDT
Categories: InterScript
Date: 25 April 1983 11:17 am PDT (Monday)
From: Lampson.PA
Subject: Remote stuff
To: Ayers, Horning, Mitchell
cc: Lampson

To: Ayers, Horning, Mitchell

-----------
Here are the declarations for TAG and TYPE, together with some useful auxiliary
stuff.

I changed TYPE slightly, adding explicit code and tags attributes. The predicate
that gets tested is 
	(code=TypeCode.Any or code=TYPECODE(A)) AND
	(if code=TypeCode.Node then 
		{t_REVEAL(A) tags SUBSETOF t.tags}!0 else 1) AND
	predicate

TAG%_{TAG$
	attributes_{
		attributes_{TYPE$ 
		   -- Fix this
		predicate%_'HASTYPE(TypeBindingsList^, REVEAL(A).bindings)'
		   default_{}}
		requiredTags_AtomList^
		contentType_{Type^ | default_Any^}
		nodeInvariant_{Predicate^ | default%_'1'}
		hasMoreInv_{Bool^ | default_0}
		reducesTo_{Any^ | 
			predicate%_'A^=NIL OR
TYPECODE(A^)=TypeCode.Quoted^'}
	contentType_None^
-- The rest of these could be defaulted, but are here for clarity
	requiredTags_{}
	nodeInvariant%_'1'
	hasMoreInv_0
	reducesTo_NIL}

TYPE%_{TAG$
	attributes_{
		code_{TypeCode^ | default_TypeCode.Node^}
		tags_AtomList^
		predicate_{Predicate^ | default%_'1'}
		default_{Any^ | default_NIL --Minimal automatic default--} }
	contentType_None^}


-- Auxiliary stuff for TypeBindingsList
TypeBindingsList%_{TYPE$ tags_{TB}}
TB%_{TAG$ contentType_{TYPE$ predicate%_'HASTYPE(Type^, A^!1)'}}

-- New primitives for writing predicates
REVEAL: [n: node]->node={	--NOTE: This is a meta-definition
			length~-index of last content item in n-- 
			content_VItems(n^), 
			tags_Tags(n^),
			bindings_bindings(n^)
			attrNames_--names in bindings(n^)-}
TYPECODE: Any->TypeCode
SUBSETOF: [AtomList, AtomList]->Bool
AND, OR, NOT: [Bool, Bool]->Bool
HASTYPE: [Type, Value]->Bool
MAP: [n: Node, f: Any->Any]->Node --replaces each n!i with {A_n!i f%}!0
REDUCE: [Node, Any, [Any, Any]->Any]]

-- Notation
0..7 --Short for {TYPE$ code_TypeCode.Int^ predicate%_'A^>=0 AND A^<=7'}}

ONEOF {N0 N1 ... Nk} --Short for {TYPE$
	code_TypeCode.Int^ predicate%_'A^>=0 AND A^<=k'
	N0%_0 N1%_1 ... Nk%_k }

IF t THEN e1 ELSE e2 --Short for {e1 e2}!(t=0)

FOR x IN n COLLECT c --Short for {f%_c MAP(n, f)}!0}


TypeCode=ONEOF {Atom Int Vnode Num String Quoted Ind Any}  

Bool%_0..1

Atom%_{TYPE$ code_TypeCode.Atom^ default_0 --no default--}
ATOMLIST%_{TAG$ contentType_Atom^}
AtomList%_{TYPE$ tags_{ATOMLIST} default_{}}

Any%_{TYPE$ code_TypeCode.Any^}
None%_{TYPE$ predicate%_'0'}	--Useful for forbidding content
Predicate%_{TYPE$ code_TypeCode.Quoted^}

Type%_{TYPE$ tags_{TYPE} default_Any^}
String%_{TYPE$ code_TypeCode.String^}
Number%_{TYPE$ code_TypeCode.Number^}
	
-------------
Remote and running stuff

GETV%_{TAG$ 
	attributes_{how_ONEOF{RUNNING REMOTE} arg_Atom^ val_Any^
			 inc_Number^} }
SHOW%_{TAG$ 
	attributes_{pic_String^ val_Any^}
GET%_{TAG$ 
	attributes_{from_Atom^}


Sample usage

{TEXT$
	GETV$	how_RUNNING	arg_FigNum		val_3  inc_1
			how_REMOTE	arg_ExampleFig	val_3
	SHOW$	pic_<ZZ9>
	<3> }

{TEXT$
	GET$	from_ExampleFig
	<3> }

GETV RUNNING sets the val to inc^ + the val of previous GETV RUNNING
with the same arg, if there is one. Otherwise it leaves it unchanged.

GETV REMOTE sets the val to the val of the node labeled arg^

SHOW takes val^, converts it to a string using pic^, and replaces the content
with the result.

GET replaces the content with the content of the node labeled from^.


Note that only SHOW is guaranteed to produce a string. However, the presence of
TEXT$ in the examples means that the content had better be a string, otherwise
its invariant isn't
satisfied.

Example:
{CAPTION$ 
	{TEXT$ <Figure > }
	{TEXT$ 	GETV$ how_RUNNING arg_FigNum inc_1 val_3
			SHOW$ pic_<ZZ9>
			<3>
			ExampleFig: }
	{TEXT$ <: Example>} }

{TEXT$ <See figure >} {TEXT$ GET$ from_ExampleFig}
{TEXT$ <, in which .....>}


To do Star-style fillin rules, in which the content of remote fields is retrieved
and used in a "Mesa expression", you write
{TEXT$ STARFIELD$ 	args_{	x%^{GET$ from_XField} 
						y%^{GET$ from_YField}
				how_<string for CUSP expression> 
	<123> }
if <123> was the value computed last time.


---------------

For page headings we introduce a new feature of pouring, called VACUUM$.
This node is just like a MOLD$, except that v matches, and is replaced in the
pour by 
	w moldedBy v, 
	   where w=x.sources!i 
		where x=Parent^j(Neighbor)
such that j is the smallest integer such that x is tagged VACSOURCE and i is the
smallest integer such that w satisfies v.
	where Neighbor is gk .......


t=.... 	{red MOLD$ LINE$} 	--3
	{red VACUUM$ secH_# which_prev|succ} 
	{red MOLD$ LINE$}....	--4

g={CHAP$ chHead_<Chap 3>
	{SEC$ secHead_<Sec 3.1>
		{...} ... {red LINE$ xxx --3--} ... }
	{SEC$ secHead_<Sec 3.2>
		{...} ... {red LINE$ yyy --4--} ... }
   }

yields
	{red LINE$ xxx --3--} {red  secH_<Sec 3.1>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 3 as neighbor
	{red LINE$ xxx --3--} {red  secH_<Sec 3.2>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 4 as neighbor


---------

Labels: 
	x:
is short for
	labels_{labels | x}
and you had better put
	l^|
at the start of the node, where
	l_{LABEL$ labels_{}}

----------
Pouring streams

Stream coloring: MOLD$ and GALLEY$ have stream as a ra, and you bind an
atom to it.

{POUR$ template_{RE$ ...} galleyContent} results in 
{CAST$ resultOfPourContent rem_{remainderOfGalley}}

----------

Togetherness

{... TOG$ penalties_{{weight_number level_atom} ...} which_atom ...}
means that any pair of TOG$ nodes with the same which^ should be kept
together.

In a value (node) w, for each pair of nodes <x, y> with  TOG$ and the same
which^, we compute a penalty
	P(w, x, y)=
	  Sum over all <weight, level> pairs in x.penalties union y.penalties
		weight*|Father(w', x).number-Father(w', y).number|
			where w'=Number(w, lambda x in level in x.labels)
			and Father(w, x) is the father of x in the tree w

-------------
*start*
05993 00099 US 
gvMsgID: Lampson.PA $ 3#217@25-Apr-83 12:26:00 PDT
Categories: InterScript
Date: 25 April 1983 12:25 pm PDT (Monday)
From: Lampson.PA
Subject: Remote stuff
To: Ayers, Horning, Mitchell
cc: Lampson

To: Ayers, Horning, Mitchell

-----------
Here are the declarations for TAG and TYPE, together with some useful auxiliary
stuff.

I changed TYPE slightly, adding explicit code and tags attributes. The predicate
that gets tested is 
	(code=TypeCode.Any or code=TYPECODE(A)) AND
	(if code=TypeCode.Node then 
		{t_REVEAL(A) tags SUBSETOF t.tags}!0 else 1) AND
	predicate

TAG%_{TAG$
	attributes_{
		attributes_{TYPE$ 
		   -- Fix this
		predicate%_'HASTYPE(TypeBindingsList^, REVEAL(A).bindings)'
		   default_{}}
		requiredTags_AtomList^
		contentType_{Type^ | default_Any^}
		nodeInvariant_{Predicate^ | default%_'1'}
		hasMoreInv_{Bool^ | default_0}
		reducesTo_{Any^ | 
			predicate%_'A^=NIL OR
TYPECODE(A^)=TypeCode.Quoted^'}
	contentType_None^
-- The rest of these could be defaulted, but are here for clarity
	requiredTags_{}
	nodeInvariant%_'1'
	hasMoreInv_0
	reducesTo_NIL}

TYPE%_{TAG$
	attributes_{
		code_{TypeCode^ | default_TypeCode.Node^}
		tags_AtomList^
		predicate_{Predicate^ | default%_'1'}
		default_{Any^ | default_NIL --Minimal automatic default--} }
	contentType_None^}


-- Auxiliary stuff for TypeBindingsList
TypeBindingsList%_{TYPE$ tags_{TB}}
TB%_{TAG$ contentType_{TYPE$ predicate%_'HASTYPE(Type^, A^!1)'}}

-- New primitives for writing predicates
REVEAL: [n: node]->node={	--NOTE: This is a meta-definition
			length~-index of last content item in n-- 
			content_VItems(n^), 
			tags_Tags(n^),
			bindings_bindings(n^)
			attrNames_--names in bindings(n^)-}
TYPECODE: Any->TypeCode
SUBSETOF: [AtomList, AtomList]->Bool
AND, OR, NOT: [Bool, Bool]->Bool
HASTYPE: [Type, Value]->Bool
MAP: [n: Node, f: Any->Any]->Node --replaces each n!i with {A_n!i f%}!0
	--Example: {f_'A<4' {3 4 5} MAP f}!0={1 0 0}
REDUCE: [Node, Any, [Any, Any]->Any]]

-- Notation
0..7 --Short for {TYPE$ code_TypeCode.Int^ predicate%_'A^>=0 AND A^<=7'}}

ONEOF {N0 N1 ... Nk} --Short for {TYPE$
	code_TypeCode.Int^ predicate%_'A^>=0 AND A^<=k'
	N0%_0 N1%_1 ... Nk%_k }

IF t THEN e1 ELSE e2 --Short for {e1 e2}!(t=0)


TypeCode=ONEOF {Atom Int Vnode Num String Quoted Ind Any}  

Bool%_0..1

Atom%_{TYPE$ code_TypeCode.Atom^ default_0 --no default--}
ATOMLIST%_{TAG$ contentType_Atom^}
AtomList%_{TYPE$ tags_{ATOMLIST} default_{}}

Any%_{TYPE$ code_TypeCode.Any^}
None%_{TYPE$ predicate%_'0'}	--Useful for forbidding content
Predicate%_{TYPE$ code_TypeCode.Quoted^}

Type%_{TYPE$ tags_{TYPE} default_Any^}
String%_{TYPE$ code_TypeCode.String^}
Number%_{TYPE$ code_TypeCode.Number^}
	
-------------
Remote and running stuff

GETV%_{TAG$ 
	attributes_{how_ONEOF{RUNNING REMOTE} arg_Atom^ val_Any^
			 inc_Number^} }
SHOW%_{TAG$ 
	attributes_{pic_String^ val_Any^}
GET%_{TAG$ 
	attributes_{from_Atom^}


Sample usage

{TEXT$
	GETV$	how_RUNNING	arg_FigNum		val_3  inc_1
			how_REMOTE	arg_ExampleFig	val_3
	SHOW$	pic_<ZZ9>
	<3> }

{TEXT$
	GET$	from_ExampleFig
	<3> }

GETV RUNNING sets the val to inc^ + the val of previous GETV RUNNING
with the same arg, if there is one. Otherwise it leaves it unchanged.

GETV REMOTE sets the val to the val of the node labeled arg^

SHOW takes val^, converts it to a string using pic^, and replaces the content
with the result.

GET replaces the content with the content of the node labeled from^.


Note that only SHOW is guaranteed to produce a string. However, the presence of
TEXT$ in the examples means that the content had better be a string, otherwise
its invariant isn't
satisfied.

Example:
{CAPTION$ 
	{TEXT$ <Figure > }
	{TEXT$ 	GETV$ how_RUNNING arg_FigNum inc_1 val_3
			SHOW$ pic_<ZZ9>
			<3>
			ExampleFig: }
	{TEXT$ <: Example>} }

{TEXT$ <See figure >} {TEXT$ GET$ from_ExampleFig}
{TEXT$ <, in which .....>}


To do Star-style fillin rules, in which the content of remote fields is retrieved
and used in a "Mesa expression", you write
{TEXT$ STARFIELD$ 	args_{	x%^{GET$ from_XField} 
						y%^{GET$ from_YField}
				how_<string for CUSP expression> 
	<123> }
if <123> was the value computed last time.


---------------

For page headings we introduce a new feature of pouring, called VACUUM$.
This node is just like a MOLD$, except that v matches, and is replaced in the
pour by 
	w moldedBy v, 
	   where w=x.sources!i 
		where x=Parent^j(Neighbor)
such that j is the smallest integer such that x is tagged VACSOURCE and i is the
smallest integer such that w satisfies v.
	where Neighbor is gk .......


t=.... 	{red MOLD$ LINE$} 	--3
	{red VACUUM$ secH_# which_prev|succ} 
	{red MOLD$ LINE$}....	--4

g={CHAP$ chHead_<Chap 3>
	{SEC$ secHead_<Sec 3.1>
		{...} ... {red LINE$ xxx --3--} ... }
	{SEC$ secHead_<Sec 3.2>
		{...} ... {red LINE$ yyy --4--} ... }
   }

yields
	{red LINE$ xxx --3--} {red  secH_<Sec 3.1>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 3 as neighbor
	{red LINE$ xxx --3--} {red  secH_<Sec 3.2>} {red LINE$ yyy --4--}
if which=prev, so that the VACUUM has node 4 as neighbor


---------

Labels: 
	x:
is short for
	labels_{labels | x}
and you had better put
	l^|
at the start of the node, where
	l_{LABEL$ labels_{}}

----------
Pouring streams

Stream coloring: MOLD$ and GALLEY$ have stream as a ra, and you bind an
atom to it.

{POUR$ template_{RE$ ...} galleyContent} results in 
{CAST$ resultOfPourContent rem_{remainderOfGalley}}

----------

Togetherness

{... TOG$ penalties_{{weight_number level_atom} ...} which_atom ...}
means that any pair of TOG$ nodes with the same which^ should be kept
together.

In a value (node) w, for each pair of nodes <x, y> with  TOG$ and the same
which^, we compute a penalty
	P(w, x, y)=
	  Sum over all <weight, level> pairs in x.penalties union y.penalties
		weight*|Father(w', x).number-Father(w', y).number|
			where w'=Number(w, lambda x in level in x.labels)
			and Father(w, x) is the father of x in the tree w

-------------
*start*
03562 00098 US 
gvMsgID: ESMURA.ES $ 44#35@28-Apr-83 14:25:12 PDT
Categories: InterScript
Date: 28 April 1983 2:25 pm PDT (Thursday)
From: ESMURA.ES
Subject: Available Documentation
To: Pellar.es,Pierce.dlos
cc: Schwartz.PA, ESMura.es, UIBMembers^.PA, PrintStds^.es, DocStandards^.PA,
 Garlick.PA, Redell.PA, Ladner.PA, Alfvin.es, Becker.PA, Nikora.es, Artibee.PA,
 Bishop.PA, Casey.PA, Muirhead.PA, Porcar.PA, Thatcher.PA, Steinbach.PA
Reply-To: ESMURA

I have recently received another load of documents and many are very
interesting.  Several of them list and define new control code requirements, one
comments on the use of diacritical marks in non-Latin languages, and finally a
series of papers on blocks and frames and their BNF-Grammar.  

I list them below and will copy and forward if anypne is interested.  As before,
respond to me using Laurel and give me your mail address.  I will wait a few
days for responses and make a mailing.  

CLPT/N 158-1	Report of ad hoc meeting between Chairman of TC 97/SC 18
and Convenors of SC 18 WG 3&5. (control functions for WYSIWYG text
interchange)

CLPT/N 158-2	Draft Proposed standard for Basic Processable Text
Interchange format (definition of additional format effectors)

CLPT/N 158-3	Additional comments on draft Proposed standard for Basic
Processable Text Interchange format -CLPT/N 158-2 above.(Interim list of text
formatting control codes)

CLPT/N 159-2	Changes required to S.61 from Japan  (Select presentation
direction as left to right and top to bottom, right to left and top top to bottom,
etc.)

CLPT/N 159-3	Proposal for new control functions (soft end of line and soft
hyphen)

CLPT/N 159-4	Report of 11th meeting of TC97/SC2/WG4  Character codes
and sets (Agreement to avoid the use of NONSPACING DIACRITICS in
non-Latin sets.  Comments on  Greek, Cyrillic, Arabic, etc.. Also discussion on
fractions, publishing, and math sets)

CLPT/N 161-3	Comments on Office Document Architecture and Office
Document Interchange formats from ECMA. (addressing generic logical and
layout structures)

CLPT/N 161		IBM comments to X3L2 on hyphen/minus  and PIF and
BPTIF control functions

CLPT/N 166-1 to 5	SD-3's for standards development project, Millard Collins,
Chair X3V1

CLPT/N 168-1	Definitions of TIF and TPF by Zeckendorf (It also covers
Full Text Format - FTF)

CLPT/N 168-2	Comments on draft recommendation S.a (source is ECMA
TC29)

CLPT/N 168-3	Document Description, to supersede document WG3 N109
(provides information for handling the document as a whole)

CLPT/N 170-1	Changes to document WG3 N 110, private contribution by
Zeckendorf (talks about the structure of the data stream, control units, text units,
and attributes--comments consistent with submittals by ECMA in document WG3
N 120 and by CCITT Recommendation S.a in document WG3 N 128.

CLPT/N 170-2	The structure of text structures, by Zeckendorf ( three levels
of abstraction including interchange format describing representation of a
document in terms of data structures and transfer syntax describing coding of
data structures in terms of bits and bytes)

CLPT/N 170-3	Proposal for amending WG3 N 120, by Horak (introduces
generic logical structure as a directed graph- talks about frames and blocks and
the attrbutes of overlaying frames)

CLPT/N 170-4	Overlay of frames and Blocks, by Horak (purpose is to
improve understanding of properties of frames and blocks.)

CLPT/N 170-4	Representation of the generic logical structure and generic
layout structure of office document architecture as BNF-Grammar, by Horak

*start*
00838 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 6-May-83 15:09:17 PDT
Categories: InterScript
Date:  6-May-83 15:09:25 PDT
From: mitchell.pa
Subject: Re: Available Documentation
In-reply-to: ESMURA.es's message of 28 April 1983 2:25 pm PDT (Thursday)
To: ESMURA.es
cc: mitchell

Ed,

I would like to get copies of the following documents:

CLPT/N 170-3	Proposal for amending WG3 N 120, by Horak (introduces
generic logical structure as a directed graph- talks about frames and blocks and
the attrbutes of overlaying frames)

CLPT/N 170-4	Overlay of frames and Blocks, by Horak (purpose is to
improve understanding of properties of frames and blocks.)

CLPT/N 170-4	Representation of the generic logical structure and generic
layout structure of office document architecture as BNF-Grammar, by Horak

Thanks,

--Jim Mitchell (PARC)

*start*
07496 00101 US 
gvMsgID: pierce.dlos $ 19#130@ 9-May-83 14:20:39 PDT
Categories: InterScript
From: pierce.dlos
Date:  9-May-83 16:18:50 CDT
Subject: Document Standards
To: DocStandards^.pa
cc: BellAJ.dlos,ESmura.es,ScanStandards^.wbst,(Sam Stevens)DLOSMail.dlos,(Ron Johnson)DLOSMail.dlos

The following newsletter concerns standardization activity on document layout
characteristics.  The proposed definitions have been submitted to ANSI X3V1
for incorporation in their work on Document Architecture and Interchange
Formats.  If you have input , please respond to me.

                      STANDARDS NEWSLETTER


Subject:  Document Definitions                    5/9/83
          (Ref: X3V1.3/83-8)

A  proposed  set of document definitions was distributed to  X3V1 
TG3 members.   The definitions relate to specific uses of various 
layout  portions  of  a  page. 

Action:     These definitions should be considered for work being 
on  Interscript.   Please review the definitions and  comment  if 
appropriate.

The  following is a description of a proposed page to be used for 
the  development  of document interchange standards  within  ANSI 
X3V1.3,  Text Structures.   Not all of the elements are required, 
but the definitions and relationships are valid if these elements 
are used.

Element             Definition 

Top Trim Margin     The area between the top edge of a sheet  and 
                    the top crop line.

Top Binding Margin  The area between the top trim margin and the 
                    top margin.

Top  Margin         The area between the top binding margin  and 
                    the first header.

Header              The area into which headers are placed.

Header Margin       The area betweem the header and the body.

Body                The area into which body text is placed.

Horizontal Fold     A point at which a horizontal fold may be
                    planned.

Footnote Area       The area at the bottom of the body area into
                    which footnotes may be placed.

Footer Margin       The area between the last position for body
                    or footnote text and the footer.

Footer              The area into which footers are placed.

Bottom  Margin      The area between the footers and the  bottom 
                    binding margin.

Bottom Binding      The area between the bottom margin and the
Margin              bottom trim margin.


Bottom Trim Margin  The area between the bottom crop line and 
                    bottom edge of the sheet.


(Note:   All  of  the  above  are  primarily  involved  with  the 
horizontal  layering  aspects of viewing a  document.   The  next 
group is generally vertical in nature when viewing a page.)


Left Trim Margin    The area between the left edge of a sheet and
                    the left crop line.

Left Binding        The area between the left crop line and the
Margin              left margin.

Left Margin         The area between the left binding margin and
                    the body text.

Vertical Fold       The point at which a vertical fold may be 
                    planned.

Column Margin       The margin between columns of body text.

Right Margin        The area between the body text and the right
                    binding margin.

Right Binding       The area between the right margin and the
Margin              right crop line.

Right Trim Margin   The area between the right crop line and the
                    edge of the sheet.

Indent (left or     The area between either left, column, or 
right)              right margin and the text.  (In progressive
                    indents   the  perception  may  be  from  the 
                    previous higher level indentation, but the
                    definition is always relative to the margin.)

Inter  Block Gap    The area within the  text  body  separating 
                    blocks of text.  (In progressive block hier-
                    archies there may be differing processes 
                    determining the size of the gaps)


In all of the above,  differences from publishing terminology and 
some publishing practices may be evident.  The terminology chosen 
here  is intended to provide the broadest understanding.   In the 
Glossary, a reader will find the linkages of terms.  Some readers 
may  note  elements  stated in other  standards  to  be  missing, 
notably areas for marginal annotations.   In this standard, it is 
possible  to  specify  printing  on  the  entire  sheet.    Where 
limitations  of  printing  capabilities  happen,   they  must  be 
recognized in the document description portion.

.pa
The  indication  above  that  text may be placed in  any  of  the 
specified  areas   is  intended  to allow  for  such  matters  as 
marginal annotations, revision marks, thumb indexing, crop marks, 
etc.   Because  the  orientation of a given page may  shift  from 
portrait  to of from landscape and/or the printing of a  document 
may be on both sides of sheets, the binding margin for a document 
may not be constant for all pages.   It is important to note that 
it  need  not alternate in some documents printed on  both  sides 
(i.e., top bound bilingual documents with language alternation.)

There  are  several blocks which have not been  described  above.  
Each may appear within any of those mentioned above.   The  first 
of these additional blocks is the subdivision of any line of text 
into  left-justified,  centered,  and  right-justified  portions.  
Each  of  these  blocks implies a possible block  of  white-space 
between  the  adajacent protions and/or the  appropriate  margin.  
Note  that  centering  and  justification  apply  relative  to  a 
specific  set  of  boundaries,   not  always  the  same  set   of 
boundaries.   Related  to the above is the white space  remaining 
between  the  text and a margin in text which is not flush  right 
(or left).  In justified text this is a variable block at the end 
of each paragraph which is appended to the inter block gap.

In general,  the blocks above relate to white-space.   Two blocks 
usually containing print are rules (both horizontal and vertical) 
and  leader (both horizontal and vertical).   Rules are bands  of 
some  pattern  (usually  solid) from Point A to Point  B  in  one 
direction, either horizontal or vertical.  Leader is used to lead 
the eye and is,  again,  a pattern (usually dots) from Point A to 
Point B in one direction,  either horizontal or vertical.   While 
diagonal  rules  and leaders do occur  (extremely  infrequently), 
they  are considered outside the domain of a document  conforming 
to the standard document architecture.

The  remaining blocks needed to fill the generic page  are  those 
containing the text.   The body text block contains the paragraph 
structure blocks.   Figures, illustrations, and tables may appear 
within  or  spread  across the text body  area  (particularly  in 
columnar  text).   Some blocks may float,  that is,  the block is 
intended  to  be  held  together as  a  unit,  but  appear  at  a 
convenient,  but constrained,  place in the composed document.  A 
block  may be subject of a keep operation whereby the information 
is intended to be kept adajacent to related text.   A footnote is 
an example of a floating block with an associated keep.

Within the text,. the blocks comprising a line, word, characters, 
and spaces (fixed, variable, and tabulations) may appear.
*start*
00952 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 9-May-83 21:07:57 PDT
Categories: InterScript
Date:  9 May 83 21:06:48 PDT (Monday)
From: Ayers.PA
Subject: M I O
To: Lampson, Horning, Mitchell
cc: Ayers

I have been running around here like the proverbial chicken instead of writing up the MIO.  We're reorganizing the hell out of everything, and the dust isn't due to settle for a while ...

BUT Interscript is one of the things that is due to pop-to-the-top as we (OSD) get our act together; I'm planning on honest work this week and next, except for the $%~&* meetings.  [Meetings currently at least half of Tue, Wed (in El Seg) Fri, next Tue and Wed!]

I'm sending this so that you won't think I've disappeared.

Bob

PS to Horning on the 1FZZ999 => 2AAA000 license plate hypothesis: it sounded good at the time, but since then I've seen three 1Gxxnnn plates. Latest was a 1GUxnnn.  Do you suppose they are still giving out the blue plates too?
*start*
04270 00101 US 
gvMsgID: pierce.dlos $ 19#130@12-May-83 13:37:12 PDT
Categories: InterScript
From: pierce.dlos
Date: 12-May-83 15:35:21 CDT
Subject: Generic Documents
To: DocStandards^.pa
cc: ESmura.es,(P.England ESCP P316)ESMail.es,GRoberts.es,(M.Henderson)DLOSMail.dlos,(Ron Johnson-Mal Williams-)DlOSMail.dlos

                      STANDARDS NEWSLETTER
                                             
5/12/83                                           Roy Pierce
                                                  Pierce.dlos
(Reference data available)                        Dallas,MS191
                                                  8-723-7329



SUBJECT

     Standardized Documents


APPLICATIONS TO XEROX:  
     
     *  Forms fill in software development
     *  Forms generation and printing
     *  Document interchange standards development
     *  Workstation applications programs
     *  Work group data types and applications


INTRODUCTION

     The  ECE (Economic Commission For Europe) has adopted a list 
     of standardized documents to facilitate international  trade 
     procedures.   These documents are grouped into 9 application 
     areas  (refer  to  following  list).    There  are  numerous 
     document  types within each of the 9 application  areas  and 
     each  type has a 3 digit numeric identifier for  transaction  
     and eventually interchange purposes.   Each document type is 
     defined with a description of the function it is intended to 
     perform.


APPLICATION AREAS

     The  trade documents are grouped into 9 application areas as 
     follows:

     *  Production
     *  Purchase
     *  Sale
     *  Payment-Banking
     *  Insurance
     *  Intermediary services and  handling  (forwarding,  cargo 
        handling, warehousing, terminals and ports, etc.)
     *  Transport
     *  Exit regulations
     *  Entry and transit regulations

.pa
EXAMPLE OF NUMERIC IDENTIFIERS

     Documents  within applications area #1 are identified with 3 
     digit numeric tags as follows:

     105  Purchase order
     110  Manufacturing instructions
     120  Stores requisition
     130  Invoicing data sheet
     140  Packing instructions
     150  Internal transport order
     190  Statistical and other administrative documents


BACKGROUND

     The  handling  of "trade data" includes two major  types  of 
     activity:  processing  and transmission.   The initial  work 
     done   in   this  area  was  primarily  in  the   field   of 
     presentation,  i.e.  the  method of entering data on  forms.  
     The   only  transmission  technique  of   relevance,   until 
     recently, has been the forwarding of documents by mail.

     Advances  in  processing  and  interchange  technology  have 
     greatly improved the potential for economy and efficiency in 
     business operations.   This potential has stimulated trading 
     partners,  fowarders,  carriers  of all modes and government 
     agencies to consider the use of more automated means for the 
     interchange of trade and transport data.

     When  data are interchanged between trade partners by  means 
     other  than  paper documents,  the need arises to  agree  on 
     common   methods  and  standards  (including  semantic   and 
     syntactic  rules)  which determine the  performance  of  the 
     functions in data interchange.


COMMENTS

     The  development of  data transport services for trade  data 
     is primarily being done at the "Application Level Protocols" 
     as  distinguished  from  "Session  Level"  and  lower  level 
     communication protocols (ISO definitions).   The development 
     will  be  accomplished  by the coordinated work  of  several 
     groups such as ISO, CCITT, and ECMA.

     Within the US,  ANSI X3V1 "Office Systems" is starting  work 
     on  the classification of document types for the purpose  of 
     facilitating document interchange.  The next meeting of X3V1 
     in June will address this topic in detail.

     This  overall  activity is expected to influence the way  an 
     operator  uses a "workstation",  what features a workstation 
     must have,  and how that workstation works within local  and 
     distant networks.  

*start*
02144 00098 US 
gvMsgID: ESMURA.ES $ 44#35@13-May-83 10:05:01 PDT
Categories: InterScript
Date: 13 May 1983 10:04 am PDT (Friday)
From: ESMURA.ES
Subject: Re: Generic Documents
In-reply-to: pierce.dlos's message of 12-May-83 15:35:21 CDT
To: pierce.dlos
cc: DocStandards^.pa, ESmura,(P.England ESCP
 P316)ESMail,GRoberts,(M.Henderson)DLOSMail.dlos
Reply-To: ESMURA

Very interesting.  I'd like to report that last week X3J6 voted to submit parts 1, 2,
5, & 6 of the new standard (a DIS) for international comment.  Parts 3 & 4 are
also being circulated as working paper examples.  Part 6, Document Markup
Metalanguage specifies a notation that describes the structure and attributes of
documents generically, without respect to the processing that they will undergo.
The documents can therefore be used with a multiplicity of sustems, devices,
and applications.

Also approved was the task group proposal for the Registration Procedure Task
Group.  This group will write part 10 of the standard, it specifies registration
procedures for text processing constructs defined in other parts of the standard. 
Registration minimizes duplicate development, and facilities shared use, of
constructs that are inappropriate to standards.

The registration will include accepted entity names, sets of entity names,
common element types, proforma document and element types, data content
natations, etc..  The registry is not seen to be central and singular but a series of
registries.  For example, GCA is planning a registry for government standards
and related documents.  They are very interested in the IRS activity which is
creating an electronic form of 1040's and other tax forms using TRULY GENERIC
MARKUP as defined in our standard.

This month GCA is planning to accept part 6 of the standard at their board
meeting.  This I understand makes this part of the standard a commercial
standard.  It also allows the Feds to reference this commercial standard in future
procurements.  DOD is pushing for this to happen, to standardize all military
documentation.  The assistant undersecretary for technology has worked closely
with GCA.

ED

*start*
03460 00099 US 
gvMsgID: Horning.pa $ 3#203@13-May-83 17:03:23 PDT
Categories: InterScript
Date: 13-May-83 17:03:16 PDT
From: Horning.pa
Subject: Last year's concern
To: Lampson, Mitchell, Ayers
cc: Horning 

-------------------------------------
Date: 10 Feb. 1982 5:53 pm PST (Wednesday)
Sender: Horning.pa
From: Mitchell, Horning
Subject: Re: Draft of letter to Liddle about InterDoc - Over to you
To: Lampson
cc: Mitchell, Horning

Butler,

Jim and I seem to have converged. Now you can make it right.

Jim M. and Jim H.

-------------------
Dear David,

This is to express our concern about the lack of priority given by OSBU to the
project developing a Standard for the Interchange of Editable Documents. We
believe that some changes are necessary if Xerox is to develop, in a timely
manner, a viable means for interchanging documents among its various products.

As you will recall, the Systems Integration and Standards Board approved this
project at its last meeting. The proposal suggested investing 8-10 man-years
between October 1981 and February 1983. Subsequently, two groups were formed
to carry out this work, building on the InterDoc work started in CSL by the
three of us. Charles Irby heads the Standards Subcommittee; Bob Ayers is leading
the Technical Working Group. We have full confidence that Charles and Bob
will do excellent jobs, if they are given the necessary time and resources.

Under the present OSBU priorities, however, we do not expect an acceptable
standard to be developed on the SISB schedule. An estimated eight to ten
man-years of technical work are needed to develop a standard, document it
adequately, and test it with a trial implementation for Star. Almost none of that
investment has yet been made. The current level of effort on the project is
somewhat less than one full-time equivalent.

We have two major suggestions:

Firstly, people must be assigned to this work full-time. No one has this project as
his primary assignment. Bob Ayers has had to take on the Technical Working
Group without being relieved of his other responsibilities. The project needs five
people from OSBU full time, in addition to personnel from Research and other
parts of the corporation. If those full-time people were available today, it would
still take them more than a year to complete the job.

Secondly, Charles and Bob must control these resources. Personnel are always in
short supply, and every manager has urgent work for his staff. If those working
on the standard must split their efforts, work will proceed at a fraction of the
full-time pace. This is exactly what is happening right now in Bob's case,
because of the necessarily high priority of Star performance improvements.    

Of course, you could decide that interchanging documents is not sufficiently
urgent to justify more OSBU resources. The problem will not go away, but
InterDoc can continue as a background project until a crisis develops. At that
point it will be too late to greatly accelerate the development by throwing
resources at it, and some externally-developed standard will probably be adopted.
This would destroy the primary rationale Research has had for participation in
this project. We would return to tasks where our talents are in more urgent
demand.

Respectfully,

Jim Mitchell
Jim Horning
Butler Lampson

c: Shoch, Irby, Ayers, Taylor, Spinrad, Pake, Elkind, Bhushan
------------------------------------------------------------

*start*
04482 00097 US 
gvMsgID: Ayers.PA $ 60#91@15-May-83 13:42:34 PDT
Categories: InterScript
Date: 15 May 83 13:42:37 PDT (Sunday)
From: Ayers.PA
Subject: fyi
To: Lampson, Horning, Mitchell

[Thanks for the additional poke, Jim]

----------------------------------------------------------------
Date: 14 May 83 23:29:02 PDT (Saturday)
From: Ayers.PA
Subject: Writer for Interscript
To: Linden
cc: Ayers

The attached message (15 months old) is relevant to our discussion of Thursday on Interscript, documentation, and manpower.

Ted, I'm viewing it as your job to keep Interscript covered and to "pick up the slack."  I'm not a full-time Interscript guy, and we (OSD) need one.  Or more.

The recent "Goals of Star Redesign Project" of Bergsteinssen/Elkind/Weaver is quite specific about a strong role for Interscript in the product strategy.  If one believes it, one can easily see that the Standards group needs a full-time Interscript person, and Star also needs one.  Right now, I don't see where either of those people will come from.

I will be interested to hear of your talk with Curry.

Bob 


-------------------------------------
Date: 10 Feb. 1982 5:53 pm PST (Wednesday)
Sender: Horning.pa
From: Mitchell, Horning
Subject: Re: Draft of letter to Liddle about InterDoc - Over to you
To: Lampson
cc: Mitchell, Horning

Butler,

Jim and I seem to have converged. Now you can make it right.

Jim M. and Jim H.

-------------------
Dear David,

This is to express our concern about the lack of priority given by OSBU to the
project developing a Standard for the Interchange of Editable Documents. We
believe that some changes are necessary if Xerox is to develop, in a timely
manner, a viable means for interchanging documents among its various products.

As you will recall, the Systems Integration and Standards Board approved this
project at its last meeting. The proposal suggested investing 8-10 man-years
between October 1981 and February 1983. Subsequently, two groups were formed
to carry out this work, building on the InterDoc work started in CSL by the
three of us. Charles Irby heads the Standards Subcommittee; Bob Ayers is leading
the Technical Working Group. We have full confidence that Charles and Bob
will do excellent jobs, if they are given the necessary time and resources.

Under the present OSBU priorities, however, we do not expect an acceptable
standard to be developed on the SISB schedule. An estimated eight to ten
man-years of technical work are needed to develop a standard, document it
adequately, and test it with a trial implementation for Star. Almost none of that
investment has yet been made. The current level of effort on the project is
somewhat less than one full-time equivalent.

We have two major suggestions:

Firstly, people must be assigned to this work full-time. No one has this project as
his primary assignment. Bob Ayers has had to take on the Technical Working
Group without being relieved of his other responsibilities. The project needs five
people from OSBU full time, in addition to personnel from Research and other
parts of the corporation. If those full-time people were available today, it would
still take them more than a year to complete the job.

Secondly, Charles and Bob must control these resources. Personnel are always in
short supply, and every manager has urgent work for his staff. If those working
on the standard must split their efforts, work will proceed at a fraction of the
full-time pace. This is exactly what is happening right now in Bob's case,
because of the necessarily high priority of Star performance improvements.    

Of course, you could decide that interchanging documents is not sufficiently
urgent to justify more OSBU resources. The problem will not go away, but
InterDoc can continue as a background project until a crisis develops. At that
point it will be too late to greatly accelerate the development by throwing
resources at it, and some externally-developed standard will probably be adopted.
This would destroy the primary rationale Research has had for participation in
this project. We would return to tasks where our talents are in more urgent
demand.

Respectfully,

Jim Mitchell
Jim Horning
Butler Lampson

c: Shoch, Irby, Ayers, Taylor, Spinrad, Pake, Elkind, Bhushan
------------------------------------------------------------


----------------------------------------------------------------

----------------------------------------------------------------
*start*
00788 00097 US 
gvMsgID: Ayers.PA $ 60#91@19-May-83 19:45:46 PDT
Categories: InterScript
Date: 19 May 83 19:45:46 PDT (Thursday)
From: Ayers.PA
Subject: Oversight in Solid Layout Memo?
To: Lampson
cc: Ayers, Horning, Mitchell

page two of message of 22 April 1983 11:34 PST:

    else if how.method=onOrigins then
      B'=B except for i in [0..B.n]
        let cl=B.xy.l.e-B!i.xy.l.e
        -- --
        B'!i=FixMeasures[{B!i | xy.cl_MkFixedMeasure[cl], xy]
    
This formulation calculates the containeeLow of the interior box by subtracting the (not-yet-fixed) lowPart of the interior box from the (fixed) lowPart of the exterior box.

This means that the "o" and "u" of the lowpart of a box layed out "onOrigins" do not enter into the calculations.  Do we believe this?    
*start*
01273 00097 US 
gvMsgID: Ayers.PA $ 60#91@20-May-83  8:59:56 PDT
Categories: InterScript
Date: 20 May 83 08:59:58 PDT (Friday)
From: Ayers.PA
Subject: Oversight Correction?
To: Lampson
cc: Ayers, Horning, Mitchell

After thought, I propose to alter the calculation of onOrigins to use the standard method: using Decompose-SetGlue-Recompose on the set of two values interiorbox.l and interiorbox.cl.

Reply only if you think this is bad.

Bob

----------------------------------------------------------------
Date: 19 May 83 19:45:46 PDT (Thursday)
From: Ayers.PA
Subject: Oversight in Solid Layout Memo?
To: Lampson
cc: Ayers, Horning, Mitchell

page two of message of 22 April 1983 11:34 PST:

    else if how.method=onOrigins then
      B'=B except for i in [0..B.n]
        let cl=B.xy.l.e-B!i.xy.l.e
        -- --
        B'!i=FixMeasures[{B!i | xy.cl_MkFixedMeasure[cl], xy]
    
This formulation calculates the containeeLow of the interior box by subtracting the (not-yet-fixed) lowPart of the interior box from the (fixed) lowPart of the exterior box.

This means that the "o" and "u" of the lowpart of a box layed out "onOrigins" do not enter into the calculations.  Do we believe this?    

----------------------------------------------------------------
*start*
00559 00097 US 
gvMsgID: Ayers.PA $ 60#91@20-May-83 15:39:54 PDT
Categories: InterScript
Date: 20 May 83 15:39:54 PDT (Friday)
From: Ayers.PA
Subject: Latest "pouring" memo?
To: Lampson
cc: Mitchell, Horning, Ayers

I have a BWL memo which is eight pages long and discusses pouring&res and encoding, and ends with three 'questions'  
[I lack the first page, so cannot date it]

I'm operating from that memo plus the meeting notes of 18 April and 24 April.

Bob

PS: am I correct that we decided to leave the fancy ad-hoc 'limits' out of the standard?
*start*
00287 00097 US 
gvMsgID: Ayers.PA $ 60#91@23-May-83 13:38:59 PDT
Categories: InterScript
Date: 23 May 83 13:39:03 PDT (Monday)
From: Ayers.PA
Subject: MIO Progress
To: Mitchell, Horning, Lampson

I will have draft rewrites of chapters four and five out by the end of the week.  
*start*
01039 00098 US 
gvMsgID: ESMURA.ES $ 44#35@24-May-83  9:37:07 PDT
Categories: InterScript
Date: 24 May 1983 9:39 am PDT (Tuesday)
From: ESMURA.ES
Subject: Computer Graphics Virtual Device Metafile 
To: Pierce.DLOS
cc: ESMura, UIBMembers^.pa, PrintStds^, DocStandards^.pa, Garlick.pa, Redell.pa,
 Ladner.pa, Alfvin, Becker.pa, Nikora, Artibee.pa, Bishop.pa, Casey.pa,
 Muirhead.pa, Porcar.pa, Thatcher.pa, Steinbach.pa,Biellak.WBST
Reply-To: ESMURA

I have a copy of the proposed American National Standard for the Computer
Graphics Virtual Device Metafile. This might be of interest to some of you as a
mechanism to allow the integration of computer-generated graphics with text in a
standard way.

The document is currently out on a letter ballot within X3H3. It  will be sent to
X3 for SPARC approval and public comment in mid-summer.

If you want a copy reply by Laurel by May 27, 1983.  The document is 170
pages and I will only make one request of REPRO.  In addition, please include
your mail stop if you want delivery.

ED

*start*
01044 00098 US 
gvMsgID: paxton.pa $ 3#185@24-May-83 13:03:53 PDT
Categories: InterScript
Date: 24-May-83 13:03:48 PDT
From: paxton.pa
Subject: Interscript/Interpress, Pathfinder & and Visit to PARC
To: Mitchell, Horning
Reply-To: paxton
cc: Lyles.WBST

Can you guys set up a time to talk to Bryan on June 9th regarding Interscript?

--Bill

-------------------------------------
Date: 24 May 1983 2:06 pm EDT (Tuesday)
From: Lyles.WBST
Subject: Interscript/Interpress, Pathfinder & and Visit to PARC
To: Paxton.pa
cc: Lyles

Bill,

Jim Baroody gave me your name as a contact for the Interscript project.  We are
in the course of trying to reconcile Pathfinder's scanning and page make-up
services with the DPRS architecture.  I will be in El Segundo the week of June 6
and would like to come up to PARC to discuss our problems and learn the
current standards thinking on these issues.  Would you be willing to meet with
me Thursday, June 9 or refer me to someone more appropriate?

-Bryan Lyles
�Ê!˜J˜¡J˜ç—…—Œ³*start*
00578 00097 US 
gvMsgID: Ayers.PA $ 60#91@24-May-83 15:19:36 PDT
Categories: InterScript
Date: 24 May 83 15:19:43 PDT (Tuesday)
From: Ayers.PA
Subject: MIO: Query on "coordinate rotation"
To: Lampson, Mitchell, Horning
cc: Ayers

We currently have this as an attribute of BOX$.  [ref: bwl memo of 22 april]

I suggest that we should move it to be an attribute of HOWTOLAYOUT$

The HOWTOLAYOUT$ tag is added to a box node whenever there are nested box to be layed out; it currently has the attributes "method" [fixed, up, down, onOrigins] and "siblingGlueFunction".

Bob
*start*
00473 00099 US 
gvMsgID: Horning.pa $ 3#203@24-May-83 17:21:24 PDT
Categories: InterScript
Date: 24-May-83 17:22:33 PDT
From: Horning.pa
Subject: Re: MIO: Query on "coordinate rotation"
In-reply-to: "Ayers' message of 24 May 83 15:19:43 PDT (Tuesday)"
To: Ayers
cc: Lampson, Mitchell, Horning

Bob,

No, this was deliberately made an attribute of BOX$, on the grounds that coordinate systems made sense for other things than nested boxes (e.g., graphics).

Jim H.

*start*
00440 00099 US 
gvMsgID: Horning.pa $ 3#203@24-May-83 17:40:39 PDT
Categories: InterScript
Date: 24-May-83 17:41:48 PDT
From: Horning.pa
Subject: Re: Interscript/Interpress, Pathfinder & and Visit to PARC
In-reply-to: "Your message of 24-May-83 13:03:48 PDT"
To: paxton
cc: Mitchell, Horning

Bill,

I believe that I will be available on June 9. Do you have a feeling for how much time it is appropriate to give this guy?

Jim H.


*start*
00468 00100 US 
gvMsgID: mitchell.pa $ 3#171@24-May-83 22:45:05 PDT
Categories: InterScript
Date: 24-May-83 22:46:12 PDT
From: mitchell.pa
Subject: Re: Interscript/Interpress, Pathfinder & and Visit to PARC
In-reply-to: "Your message of 24-May-83 13:03:48 PDT"
To: paxton, horning
cc: mitchell

I currently have no meetings scheduled for June 9th, so I am available to talk with Bryan.  Like Jim Horning, I would like to keep it to a reasonable minimum.
--Jim
*start*
00365 00098 US 
gvMsgID: paxton.pa $ 3#185@25-May-83  8:22:54 PDT
Categories: InterScript
Date: 25-May-83  8:23:01 PDT
From: paxton.pa
Subject: Re: Interscript/Interpress, Pathfinder & and Visit to PARC
In-reply-to: "Horning's message of 24-May-83 17:41:48 PDT"
To: Horning, Mitchell


I think 1/2 hr is max.

Why don't you two contact him directly.

--Bill*start*
00462 00100 US 
gvMsgID: mitchell.pa $ 3#171@25-May-83  9:52:07 PDT
Categories: InterScript
Date: 25-May-83  9:53:16 PDT
From: mitchell.pa
Subject: Discussing Interscript
To: Lyles.WBST
cc: Horning, Paxton, mitchell

Bryan,

Jim Horning and I would be happy to talk with you about Interscript on Thursday, June 9.  I propose we meet after lunch at 1:30; I think that 30-60 minutes will probably be adequate.

Comments or conflicts anyone?

--Jim Mitchell*start*
00343 00099 US 
gvMsgID: Horning.pa $ 3#203@25-May-83 10:25:24 PDT
Categories: InterScript
Date: 25-May-83 10:25:29 PDT
From: Horning.pa
Subject: Re: Discussing Interscript - ACK
In-reply-to: "mitchell's message of 25-May-83  9:53:16 PDT"
To: Mitchell, Lyles.WBST
cc: Horning, Paxton

Jim, Bryan,

I'll put it on my calendar.

Jim H.

*start*
00729 00097 US 
gvMsgID: Ayers.PA $ 60#91@25-May-83 11:00:11 PDT
Categories: InterScript
Date: 25 May 83 11:00:09 PDT (Wednesday)
From: Ayers.PA
Subject: On reducesTo ...
To: Lampson, Horning, Mitchell
cc: Ayers

I have been writing down the "reducesTo" for PARAGRAPH$.

A concern: 

    once we have this reducesTo in the standard, it is going to be very 
    difficult to augment a PARAGRAPH$ by adding another tag, such as
    ILLUMINATEDLETTER$
    
because the PARAGRAPH$ will still expand into the stuff defined in the standard's reducesTo, and, alas, what the ILLUMINATEDLETTER$ would like to do is alter some of the insides of that.

There isn't a way to do it with bindings or anything else that I can see.

Bob
*start*
00541 00097 US 
gvMsgID: Ayers.PA $ 60#91@26-May-83 15:50:24 PDT
Categories: InterScript
Date: 26 May 83 15:50:33 PDT (Thursday)
From: Ayers.PA
Subject: Widow and Orphan Control
To: Interscript.pa

This is a poll.  Among paragraph properties are the subject controls, which allow one to say "layout so to prevent initial-line-alone-at-page-bottom and "layout so to prevent last-line-alone-at-top-of-page".

Is it important that they be separate, so one can describe a paragraph with widon-avoidance but the lack of orphan-avoidance?
*start*
00562 00097 US 
gvMsgID: Ayers.PA $ 60#91@26-May-83 20:04:17 PDT
Categories: InterScript
Date: 26 May 83 20:04:20 PDT (Thursday)
From: Ayers.PA
Subject: GALLEY$ ??
To: Lampson, Mitchell, Horning
cc: Ayers

In my notes for 24 April, I find the suggestion for "On coloring the pour"

    MOLD$ has binding to Stream  GALLEY$ has binding to Stream
    Every pour-ee has GALLEY$ tag.
    
Do we believe this?

From other discussions, I understand that a POUR$ tag supplies the labels that govern a pour, and the labels in the galley are vanilla labels.

Bob
*start*
00531 00099 US 
gvMsgID: Horning.pa $ 3#203@27-May-83 10:55:13 PDT
Categories: InterScript
Date: 27-May-83 10:55:28 PDT
From: Horning.pa
Subject: Re: Widow and Orphan Control
In-reply-to: "Ayers' message of 26 May 83 15:50:33 PDT (Thursday)"
To: Ayers
cc: Interscript

Bob,

I vote a strong MAYBE. I believe that widows are normally considered somewhat more objectionable than orphans, but that may just involve the magnitude of the penalty. It's hard to imagine penalizing either and totally ignoring the other.

Jim H.


*start*
00535 00097 US 
gvMsgID: Ayers.PA $ 60#91@27-May-83 14:03:42 PDT
Categories: InterScript
Date: 27 May 83 14:03:47 PDT (Friday)
From: Ayers.PA
Subject: Boldness is not Binary
To: Interscript.pa

A scan of a current type catalog produced the following boldness suffixes:

Light		Medium		Bold		Black
Extra Bold	Extra Light	Book		Demi
Heavy		Semi-Bold	Ultra		Regular
Ultra-Bold	Demi-Bold	Extra Black	Thin
Fat		Compact		Nord		Name/Number
Address		Sub Caption	Bold Listing	Bold Face
Book Catalogue	Heavy Catalogue	Catalog		Catalogue
*start*
00764 00099 US 
gvMsgID: Horning.pa $ 3#203@27-May-83 14:48:25 PDT
Categories: InterScript
Date: 27-May-83 14:49:34 PDT
From: Horning.pa
Subject: Re: Boldness is not Binary
In-reply-to: "Ayers' message of 27 May 83 14:03:47 PDT (Friday)"
To: Ayers
cc: Interscript

Bob,

The issue is not fontology, but editing. It is not relevant that a font catalog has 28 levels of blackness. The issue is whether it is reasonable for an editor to keep more than a binary indicator ORTHOGONAL TO FONT.

I claim that, while it is perfectly reasonable for a style to map "Bold_false Italic_false" to "Frutiger Thin" and "Bold_true Italic_true" to "Frutiger Oblique Demi-Bold", it is not reasonable to try to standardize this mapping in a font-independent manner.

Jim H.

*start*
00519 00099 US 
gvMsgID: Horning.pa $ 3#203@27-May-83 14:50:57 PDT
Categories: InterScript
Date: 27-May-83 14:52:01 PDT
From: Horning.pa
Subject: Re: GALLEY$ ??
In-reply-to: "Ayers' message of 26 May 83 20:04:20 PDT (Thursday)"
To: Ayers
cc: Lampson, Mitchell, Horning

Bob,

My memories of that discussion are fading fast. However, I don't recall that we ever abandoned GALLEY$. I believe that the issue was that there may be things within the pouree structure that are not to be matched and poured.

Jim H.


*start*
00487 00097 US 
gvMsgID: Ayers.PA $ 60#91@27-May-83 16:51:25 PDT
Categories: InterScript
Date: 27 May 83 16:51:24 PDT (Friday)
From: Ayers.PA
Subject: Boldness But ...
In-reply-to: Horning's message of 27-May-83 14:49:34 PDT
To: Horning, Interscript.pa

... did I say I was trying to make a point?  Did I raise an issue? 

I just found that list in my desk and thought it was amusing ("fat" and all); I thought about sending it to Whimsy^ but sent it to Interscript instead ... 
*start*
00305 00097 US 
gvMsgID: Ayers.PA $ 60#91@30-May-83 21:04:37 PDT
Categories: InterScript
Date: 30 May 83 21:04:43 PDT (Monday)
From: Ayers.PA
Subject: IBM Interactive Document Formatter
To: Interscript.pa, SDD-AD^.pa 

Recommended reading: the article in the 3Q82 issue of the IBM Systems Journal
*start*
00457 00097 US 
gvMsgID: Ayers.PA $ 60#91@30-May-83 21:23:56 PDT
Categories: InterScript
Date: 30 May 83 21:24:00 PDT (Monday)
From: Ayers.PA
Subject: Sections 4 and 5: Peek
To: Horning, Mitchell, Lampson
cc: Ayers

Copies are in the mail to you.  [I sent two copies to Horning so he can forward one to Butler if Butler isn't due here soon ...]

Also available as Star documents in McKinley<PubliC Ayers>Interscript Standard 4&5 of 30may83>*

Bob


*start*
00237 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 9-Jun-83 16:08:55 PDT
Categories: InterScript
Date:  9 Jun 83 16:09:16 PDT (Thursday)
From: Ayers.PA
Subject: MIO Syntax etc Sections?
To: Mitchell

Any prognosis of draft-availability?
*start*
00656 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 9-Jun-83 16:50:41 PDT
Categories: InterScript
Date:  9-Jun-83 16:50:45 PDT
From: mitchell.pa
Subject: Re: MIO Syntax etc Sections?
In-reply-to: "Your message of 9 Jun 83 16:09:16 PDT (Thursday)"
To: Ayers
cc: Mitchell

Bob,

prognosis of draft-availability: syntax and semantics all done; safety rules 25% done.  I have to finish course notes for Strathclyde course by early next week and expect to attack rest of safety rules after that.  If you would like the most up-to-date version of the syntax and semantics, let me know and I will print one and send it to you in the interoffice mail.

--Jim M.
*start*
00904 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 9-Jun-83 17:14:34 PDT
Categories: InterScript
Date:  9 Jun 83 17:14:32 PDT (Thursday)
From: Ayers.PA
Subject: fyi: Interscript Documentation
To: Linden
cc: Mitchell

----------------------------------------------------------------
Date:  9-Jun-83 16:50:45 PDT
From: mitchell.pa
Subject: Re: MIO Syntax etc Sections?
In-reply-to: "Your message of 9 Jun 83 16:09:16 PDT (Thursday)"
To: Ayers
cc: Mitchell

Bob,

prognosis of draft-availability: syntax and semantics all done; safety rules 25% done.  I have to finish course notes for Strathclyde course by early next week and expect to attack rest of safety rules after that.  If you would like the most up-to-date version of the syntax and semantics, let me know and I will print one and send it to you in the interoffice mail.

--Jim M.

----------------------------------------------------------------
*start*
02356 00097 US 
gvMsgID: Ayers.PA $ 60#91@14-Jun-83 14:45:04 PDT
Categories: InterScript
Date: 14 Jun 83 14:45:08 PDT (Tuesday)
From: Ayers.PA
Subject: fyi
To: Interscript.pa

----------------------------------------------------------------
From: pierce.dlos
Date: 14-Jun-83 16:22:10 CDT
Subject: Re: Generic Documents
In-reply-to: Ayers.PA's message of 15 May 83 13:41:20 PDT (Sunday)
To: Ayers.PA
cc: ESMURA.ES, pierce

Bob, I have just returned from several meetings (business trips) and have not
had a chance to answer the mail for some time.  I apologize for not getting
an answer to you previously.

The primary objective and program of work for X3V1 is to develop and produce
a standard for document interchange.  Within that statement are some
secondary objectives, which are:

* The interchange format is to be both national and international in scope.

* The interchange format is to be "revisable" and "processable".  Revisable in
  this context means the embedding of layout information so that the
  document can be easily reformatted at a recipients location.
  Processable means that the logical names of document elements will be embedde  in the interchange datastream so that automatic processing or layout
  formatting can occur.

At the moment the only ANSI draft standard submitted to ISO is BPTIF, which is a mnemonic for IBM's revisable interchange format that they have been 
talking about for some time.  I say that BPTIF is the same as IBM's revisable
format, which may be a little too adamant.  I strongly believe that these two
items are very close.

As stated in a previous transmittal, ISO rejected the ANSI proposed draft
standard based on the fact that it used control codes to identify the logical and layout properties of the document.  ISO is headed in the direction of using named logical objects and named layout containers within the interchange format.  ANSI was directed to
go back to the drawing board and revise BPTIF according to this new direction.

At the last meeting (June 6-10) it became obvious that IBM is attempting to
modify BPTIF moderately, by adding some logical delimiters, in order to make
BPTIF more palatable to ISO.  The remaining members on the ANSI task group are
more interested in a maajor overhaul (or starting over). 
----------------------------------------------------------------
*start*
00747 00101 US 
gvMsgID: pierce.dlos $ 19#130@20-Jun-83 15:48:45 PDT
Categories: InterScript
From: pierce.dlos
Date: 20-Jun-83 17:51:22 CDT
Subject: TLV Encoding Within Document Interchange Format
To: DocStandards^.pa
cc: (Ron Johnson)DLOSMail.dlos,Bhushan.wbst

The ISO standards organization TC97/SC18/EGCLPT has voiced a concern in hthat they are not in favor of TLV formats that would be imposed at the application level of the OSI model.  They are not concerned if the TLV concept is implemented at the Presentation or lower levels.  EGCLPT has
noted that several documents within ISO/TC97/SC18/WG3 have mentioned TLV and they feel that this technique seems ill suited for nested or interleaved
document elements.

Any comments?

Roy
*start*
00396 00100 US 
gvMsgID: mitchell.pa $ 3#171@20-Jun-83 17:22:20 PDT
Categories: InterScript
Date: 20-Jun-83 17:22:32 PDT
From: mitchell.pa
Subject: Re: TLV Encoding Within Document Interchange Format
In-reply-to: "pierce.dlos's message of 20-Jun-83 17:51:22 CDT"
To: pierce.dlos
cc: Mitchell.pa

Before I could comment, I would need to know what TLV and EGCLPT stand for.

--Jim Mitchell
*start*
01039 00101 US 
gvMsgID: pierce.dlos $ 19#130@21-Jun-83 10:01:25 PDT
Categories: InterScript
From: pierce.dlos
Date: 21-Jun-83 12:03:58 CDT
Subject: Re: TLV Encoding Within Document Interchange Format
In-reply-to: Your message of 20-Jun-83 17:22:32 PDT
To: mitchell.pa
cc: pierce

TLV stands for data type (T), Length of data field (L), and the actual content "value" (V).  This is an encoding scheme supported by CCITT (the telephone
companies of Europe).  Their latest input in this area is a proposed standard which is referred to as S.a.  

EGCLPT stands for experts group on computer languages for processing text.  This is an ISO standards body that is similar to the group that Ed Smura is on in ANSI (X3J6).  This group is the supporting 
faction for mark-up languages.  In this particular place I share their concern on using TLV encoding within document interchange formats.  My concern may be 
unfounded and that's why I asked for comments.

Hope you can give me some insight into what the impacts of TLV could be.

Roy
*start*
01310 00101 US 
gvMsgID: Wheeler.WBST $ 33#72@21-Jun-83 12:56:09 PDT
Categories: InterScript
Date: 21 June 1983 3:54 pm EDT (Tuesday)
From: Wheeler.WBST
Subject: Re: TLV Encoding Within Document Interchange Format
In-reply-to: pierce.dlos's message of 20-Jun-83 17:51:22 CDT
To: pierce.dlos
cc: DocStandards^.pa, (Ron Johnson)DLOSMail.dlos,Bhushan

Roy,

Thanks for the description of the TLV and EGCLPT.

I have two comments:

1.  Why should the document interchange format standard not be in the
presentation layer?  I think that is the logical place for one to be.  Does anyone
want to put it into the application layer of OIS?

2.  It seems to me that the TLV format simply says that the field has an
identifier, a length indicator and user data.  It is the format used on almost all
the OSI standards now under development or approved.  The alternative is to
require fixed length and a priori knowledge of "type".  What do the EGCLPT
people want to use instead of TLV?

3.  The standards work on text processing programming languages in ANSI is
done in X3J6.  This corresponds to ISO/TC97/SC5 Project 12, I believe.  Why is
there such a group in ISO/TC97/SC18?  Is it for liaison with SC5?  If such a
group of experts were put into X3V1, they would surely develop conflicts with
X3J6.

-----Jack

*start*
02778 00101 US 
gvMsgID: pierce.dlos $ 19#130@22-Jun-83  7:23:52 PDT
Categories: InterScript
From: pierce.dlos
Date: 22-Jun-83  9:26:30 CDT
Subject: Re: TLV Encoding Within Document Interchange Format
In-reply-to: Wheeler.WBST's message of 21 June 1983 3:54 pm EDT (Tuesday)
To: Wheeler.WBST
cc: pierce, DocStandards^.pa, (Ron Johnson)DLOSMail,Bhushan.WBST

John,

My comments to your questions:

1/2.  I don't think that there is a concern over TLV as long as it corresponds to the handling of the message transfer such as information on the envelope that encapsulates the message/document.  There is a fear however, that if these TLV identifiers are embedded within the document itself that there will be adverse impacts on nesting and interleaving (according to X3J6).

	There is also some confusion about what the presentation layer is and how it differs from the applications layer.  There is a large group that believes that the document format is an applications layer concept.  They don't mind addressing the "envelope" in a standardized way (type of data, length of field, etc.) but, don't start dictating the way I construct my letter inside.


3.	The X3J6 people represent the publishing industry and high volume printing operations like the IRS publishing department.  Their approach has been to develop text processing techniques that run on large front-end computers that are connected to typesetting equipment.  They are only interested in the logical structure of text and are only passively concerned with layout information.  They have used IBM's GML (Generalized Mark-Up Language) as the base line of their development effort.  The product that they have generated is now superior to GML and is called SGML or STPL.

I think a key difference between the two groups (X3J6 and X3V1) is that X3V1 is developing a document interchange format for the office environment (where formatting information is essential) and X3J6 is working primarily in languages for processing by computers.  There is considerable overlap and both X3J6 and X3V1 are starting to work closely together to come up with a document interchange format that is useful to both environments.  I feel that I have been instrumental in this "working together" as Millard Collins (X3V1 Chairman) was strongly opposed to the technical approaches of X3J6 and he felt that their environment was totally foreign to office systems.
If you were to talk with Chuck Card or James Mason (X3J6 Officers) you
will find that they are quite pleased with the new direction and cooperation they are getting from X3V1.3.

There are some areas that the two groups still need to work on, such as nesting techniques within the interchange format, but I think that these will be worked out satisfactorily.

Roy
*start*
02878 00101 US 
gvMsgID: Wheeler.WBST $ 33#72@22-Jun-83 10:02:08 PDT
Categories: InterScript
Date: 22 June 1983 1:00 pm EDT (Wednesday)
From: Wheeler.WBST
Subject: Re: TLV Encoding Within Document Interchange Format
In-reply-to: pierce.dlos's message of 22-Jun-83  9:26:30 CDT
To: pierce.dlos
cc: Wheeler, DocStandards^.pa, (Ron Johnson)DLOSMail.dlos,Bhushan
Reply-To: Wheeler

Roy,

I agree completely with your comments to my questions.

As further useful information, I have reproduced below sections of the ISO OSI
Reference Model on Application and Presentation layers.

-----Jack

         ----------------------------------------


The DIS 7498 ballots were reviewed by the ISO committee in January 1983 and a
number of editorial modifications made in order to clarify the meaning.  Note the
excerpts from the new wording below:

7.1.4	Functions within the Application Layer

The Application Layer contains all functions which imply communication
between open systems and are not already performed by the lower layers.  These
include functions performed by programs as well as functions performed by
human beings.

7.2	The Presentation Layer

7.2.2	Purpose

The Presentation Layer provides for the representation of information that
application-entities either communicate or refer to in their communication.

The Presentation Layer covers two complementary aspects of this representation
of information.

	a)	the representation of data to be transferred between
		application-entities; and

	b)	the representation of the data structure which application-entities
		refer to in their communication, along with the representations of
		the set of actions which may be performed on this data structure.

The Presentation Layer is concerned only with the syntax, i. e., the
representation of the data and not with its semantics, i. e., their meaning to the
Application Layer, which is known only by the application-entities.

The Presentation Layer provides for a common representation to be used between
application-entities.  This relieves application-entities of any concern with the
problem of "common" representation of information, i. e., it provides them with
syntax independence.  This syntax independence can be described in two ways:

	a)	the Presentation Layer provides common syntactical elements which
		are used by application-entities; and

	b)	the application-entities can use any syntax and the Presentation
		Layer provides the transformation between these syntaxes and the
		common syntax needed for communication between application-
		entities.  This transformation is performed inside the open systems.
		It is not seen by other open systems and therefore has no impact on
		the standardization of presentation protocols.

In this international standard the approach outlined in b) is used.

         ----------------------------------------


*start*
03235 00099 US 
gvMsgID: Lampson.PA $ 3#162@29-Jun-83 19:40:22 PDT
Categories: InterScript
Date: 29 June 1983 7:40 pm PDT (Wednesday)
From: Lampson.PA
Subject: Mesa for semantic functions
To: Lampson, Horning, Mitchell, Ayers
cc: Lampson

--*******VALUES*******

V: type~record[m: Mark, c: VS, x: ref_nil];
VS: type~list of V

emptyVS: VS=nil;
noV: V~[none, emptyVS]

MkVS: proc[v1, v2, v3, v4, v5: V_NoV]>[vs: VS]~{
	vs_nil; if v5#NoV then vs_cons[v5, vs];
	if v4#NoV then vs_cons[v4, vs]; if v3#NoV then vs_cons[v3, vs];
	if v2#NoV then vs_cons[v2, vs]; if v1#NoV then vs_cons[v1, vs] };

ConcatVS: proc[v1, v2, v3, v4, v5: VS_nil]>[vs: VS]~{
	vs_nil; if v5#nil then vs_Append[v5, vs];
	if v4#nil then vs_Append[v4, vs]; if v3#nil then vs_Append[v3, vs];
	if v2#nil then vs_Append[v2, vs]; if v1#nil then vs_Append[v1, vs] };

HasStruc: proc[vs: VS]>bool~{return[
	if Empty[vs] then false
	else if Singleton[vs] then IsStrucMark[vs.first.m]
	else HasStruc[vs.first] or HasStruc[vs.rest] }

Singleton: proc[vs: VS]>[bool]~{return[vs#nil and vs.rest=nil]}

Contents: proc[vs: VS]>[VS]~{return[
	if vs=emptyVS then vs
	else if Singleton[vs] then {
		v: V~vs.first; if v.m=tag or v.m=bind then emptyVS else MkVS[v]}
	else ConcatVS[Contents[vs.first], Contents[vs.rest]] }
		
--*******MARKS*******

Mark: type~	{atom, bind, bindStruc, indStruc, node, num, onodeStruc,
		 quotedStruc, scope, tag, none};
IsStrucMark: proc[m: Mark]>bool~{
	return[m=bindStruc or m=indStruc or m=onodeStruc or m=quotedStruc]}

--*******NAMES*******

-- Note that a Name is never empty; it always comes from the parser
Name: type~list of Id;
Id: type~record[a: atom];

IsId: proc[n: Name]>[bool]~{return[n.rest=nil]};

--*******REAL WORK*******

MkScope: proc[vs: VS]>[VS]~{
	if HasStruc[vs] then Contents[vs] else MkVS[[scope, Contents[vs]]] }

-- All the relevant attributes for each tag are listed at the end of a node, even if
the node's tags' relevant attribute sets are not disjoint. To place some bindings in
a node without regard for using a specific node type indicated by tags, each
binding must be a structural binding.
MkNode: proc[e: Env, vs: VS]>[V -- node--]~{return[
	[node, ConcatV[Tags[vs], Contents[vs], relBindings[e, Tags[vs]]] ] ]}

MkBinding: proc[e: Env, v: V, n: Name, kind: Mark --bind | bindStruc]>[V]~{
	if IsId[n] then return[[kind, v, n.id]]
	t: V~EvalName[e, n];
	if t.m=node then return[MkBinding[
		e, 
		ConcatVS[MkNode[e, t.c], MkVS[[kind, v, n.first ]] ],
		n.rest, kind]]
	else error }

Lookup: proc[e: Env, n: Name]>[V]~{
	if e=emptyEnv then error
	elseif IsId[n] then {
		id: Id~n.first;
		for ee: Env_e, ee.rest while ee#nil do
			b: V~e.first; if b.x=id then return[b.c] endloop;
		error }
	else return[Lookup[e~Bindings[EvalName[e, n.rest]], n~n.first] ]};

EnvForIds: proc[e: Env, n: Name]>[Env]~{
	};

EvalName: proc[e: Env, n: Name]>[V]~{
	};

Apply: proc[op: Op, v1: V, v2: V]>[V]~{
	};

Tags: proc[vs: VS]>[VS --tag items only--]~{
	};

Items: proc[v: V --a node--]>[VS]~{
	};

Bindings: proc[v: V --a node--]>[Env]~{
	};

RelBindings: proc[e: Env, vs: VS --tag items only--]>[Env]~{
	};

RefineBindings: proc[e: Env, basis: Env]>[Env]~{
	};

PullDefaults: proc[e: Env]>[Env]~{
	};


*start*
00602 00097 US 
gvMsgID: Ayers.PA $ 60#91@30-Jun-83 11:00:51 PDT
Categories: InterScript
Date: 30 Jun 83 11:02:11 PDT (Thursday)
From: Ayers.PA
Subject: ECMA Submission on Document Interchange
To: Gittins.rx
cc: Interscript.pa

I just got ECMA/TC29/83/47 via Roy Pierce.  Initial read conclusion: 

Your comment of yesterday 

    that ECMA had mentioned the dual layout (page, column, frame) 
    and galley (chapter, section, paragraph)  hierarchies, and then 
    carefully avoided discussing their interaction, preferring 
    instead to worry about coding details, 
    
was just perfect!
*start*
01332 00098 US 
gvMsgID: ESMURA.ES $ 44#35@30-Jun-83 14:40:29 PDT
Categories: InterScript
Date: 30 June 1983 2:41 pm PDT (Thursday)
From: ESMURA.ES
Subject: Available Documentation
To: pierce.dlos
cc: Schwartz.PA, UIBMembers^.PA, PrintStds^.es, DocStandards^.PA, Garlick.PA,
 Redell.PA, Ladner.PA, Alfvin.es, Becker.PA, Nikora.es, Artibee.PA, Bishop.PA,
 Casey.PA, Muirhead.PA, Porcar.PA, Thatcher.PA, Steinbach.PA
Reply-To: ESMURA

I have just received copies of X3J6's submission (dated June 1983) to ISO, the
Text Processing standard.  When ISO receives them four of the six parts it will be
given a Draft International Standard (DIS) label, these are marked *. 

The following documents are available to those who want them:

Information Processing Systems-Programming LanguagesText Interchange and
Processing-

*Part One-General

*Part Two-Vocabulary

Part Three-Programming Language (Offered only to show status, it is somewhat
behind the others in its degree of completion)

Part Four-Entry and Editing Functions (only indicative of the intended
direction)

*Part Five-Formatting and Composition Functions

*Part Six-Document Markup metalanguage

If anyone would like to see the above send me your name and mailstop
and mark what you want.  I will begin distribution about July 15th, so reply
before that date.

Ed

*start*
01084 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 7-Jul-83 16:23:30 PDT
Categories: InterScript
Date:  7 Jul 83 16:23:41 PDT (Thursday)
From: Ayers.PA
Subject: On row-template in a Table
To: Lampson, Mitchell, Horning
cc: Ayers

[Please correct the following claims as necessary]

After some discussion of the BWL pouring model, we agreed that Ayers would write up the "green" (Ayers) proposal where the CONTENT of the table node was a sequence of TABLEROWs and each tablerow had the TABLEELEMENT values for that one row within it.

[The BWL proposal aded a pour to allow all the content tableelements to be together ...]

We also agreed that a TABLE node should be expressable with a reducesTo.  There will be a binding, in the table node, of the form 

       template _ "quoted expression"
       
This will let each of the content TABLEROW nodes be something like
 
       {TABLEROW$ template^ {TABLEELEMENT$ ...} {TABLEELEMENT$ ...} ... }
       
The easiest way to insist that the TABLEROW nodes actually be shaped like the above is to give the TABLEROW node a reducesTo also.
*start*
00281 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 7-Jul-83 20:23:16 PDT
Categories: InterScript
Date:  7 Jul 83 20:23:15 PDT (Thursday)
From: Ayers.PA
Subject: Quoted Expressons vs Nodes
To: Lampson, Mitchell, Horning
cc: Ayers

Is there any difference between them these days?


*start*
00501 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 8-Jul-83 12:26:21 PDT
Categories: InterScript
Date:  8 Jul 83 12:26:11 PDT
From: mitchell.pa
Subject: Re: Quoted Expressons vs Nodes
In-reply-to: "Ayers' message of 7 Jul 83 20:23:15 PDT (Thursday)"
To: Ayers
cc: Lampson, Mitchell, Horning

yes, a quoted expression is a term, e.g., q1%_'a+b'.  One can also have a quoted expression such as q2%_'{a+b}', and then q1^ and q2^| are equivalent (even though q1% and q2%| clearly are not).  

--Jim M.
*start*
00510 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 8-Jul-83 12:41:55 PDT
Categories: InterScript
Date:  8 Jul 83 12:41:50 PDT
From: mitchell.pa
Subject: Interscript semantics, etc.
To: Lampson, Horning, Ayers
cc:  mitchell

Well guys, I tried hard to get the semantics and safety rule done before I left on this three-week trip, but I just couldn't get enough hours in each day.  I have nothing on my plate when I return, so I expect to finish it then.  I estimate about 3-4 more days are needed.

--Jim M.
*start*
00399 00099 US 
gvMsgID: Lampson.PA $ 31#14@ 8-Jul-83 12:58:30 PDT
Categories: InterScript
Date: Fri, 8 Jul 83 15:51 EDT
From: Lampson.PA
Subject: Re: Quoted Expressons vs Nodes
In-reply-to: "Ayers' message of 7 Jul 83 20:23:15 PDT (Thursday)"
To: Ayers
cc: Lampson, Mitchell, Horning

Yes. A quoted expression isn't evaluated until it is invoked, and in the environment of the invocation.

*start*
00581 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 8-Jul-83 15:34:22 PDT
Categories: InterScript
Date:  8 Jul 83 15:34:14 PDT (Friday)
From: Ayers.PA
Subject: Re: not enough hours in each day
In-reply-to: mitchell's message of 8 Jul 83 12:41:50 PDT
To: mitchell
cc: Lampson, Horning, Ayers

What state are things in?

I would like to publish chapters 4 and 5 this month, at least to friends in OSD.

Those chapters are understandable with only a rough comprehension of the syntax and semantics.  Could I have something better than the "Toward an ..." paper to accompany them?

Bob
*start*
01439 00099 US 
gvMsgID: Lampson.PA $ 31#14@ 8-Aug-83  8:17:29 PDT
Categories: InterScript
Date: Sat, 18 Apr 92 14:09 EST
From: Lampson.PA
Subject: Interscript status
To: Ayers, Horning, Mitchell, Lynch


FYI

---------------------------

Date: 5 Aug. 1983 5:56 pm PDT (Friday)
From: Lampson.PA
Subject: Interscript
To: Elkind, Shoch
cc: Lampson, Taylor, Spinrad

FYI, my opinion of the current state of Interscript.

Technical: Pretty good. I think the basic structure is sound. There are surely a
lot of minor errors in the standards, and a number of loose ends, but that's to be
expected.

General: Pretty bad. The document we have written documents the standard
fairly precisely. It is also completely unreadable (as we knew it would be; better
a precise and unreadable standard than one which means all things to all men).
Much work must be done to explain it with English and examples before anyone
can even evaluate our work, much less use it for anything. This work has not
been started. It will require some competent people and a fair bit of time. It is in
series with any further progress.

As far as I can tell, the reason for this state of affairs is that while OSD and
perhaps SG planning thinks that Interscript is important, the engineering
organization does not.

Without a substantial increase in the resources devoted to this project, it will fail.

------------------------------------------------------------

*start*
03396 00099 US 
gvMsgID: Horning.pa $ 3#203@ 8-Aug-83 11:33:46 PDT
Categories: InterScript
Date:  8 Aug 83 11:33:43 PDT
From: Horning.pa
Subject: FYI: Advice to Harold
To: Lampson, Mitchell, Ayers
cc: Taylor, Horning 

-------------------------------------
Date:  8 Aug 83 11:07:47 PDT
From: Horning.pa
Subject: Interpress & Interscript - I
To: Hall
cc: Horning

Harold,

Since I, too, seem to be having some trouble setting down a draft letter, I thought I would split up my promised response into two parts: the attempt at suggesting a Xerox position, and the suggested letter. Herewith the former.

I take it as axiomatic that there WILL be external standards for interchange of printable documents and interchange of editable documents, regardless of what Xerox does. Initially, there will doubtless be several, but economics will eventually force convergence, for generally the same reasons that Xerox must settle on a single standard for each.

Xerox appears to have a technical lead in both areas (at least over the groups we know about, including the standards bodies). We are not in a position to IMPOSE a standard, but by exhibiting a high-capability standard (together with implementations), we can certainly influence the shape and functionality of any eventual standard.

There are two principal dangers if we choose to keep our standards pure internal: ceding the "inside track" to some other company, and adoption of a "low-aspiration" standard.

The former is less serious. It means that the favored company will start out with products that are already standards-conforming, which will certainly be a publicity coup and will save them some work in developing converters. However, IF all Xerox products are already using the Xerox standard, all that will be needed to support any single new standard across the whole product line will be a pair of converters: internal/external and external/internal; this is not a much bigger deal than interfacing yet another product to the internal standard.

The second risk is potentially much greater. It is easy to envision the adoption of standards that cater to the "least common denominator," but are not extensible to include the sorts of "value added" that our feature-rich systems provide, or may provide in the future. (The analogy is restricting a bitmap printer like the 9700 to a single-font capability mimicking the 1403 printer, because that's the interchange standard.) This risk can be reduced if we can get our standards (or other equally "rich" standards) sufficiently widely used that the standards bodies cannot ignore their capabilities. For this purpose, it is NOT necessary that our standards be adopted unchanged, only that the eventual standards be just as powerful.

For both of these purposes, it seems highly desirable to get the bellwether universities interested in and using our standards. The most effective mechanism for doing this would seem to be to grant them a royalty-free license for their own use. They will certainly wish to make the software they develop available to other universities (and possibly even commercially). We should assure them that we will follow the UNIX model: nominal license fees for any academic use, substantial license fees for commercial use (and higher for development than for per-machine usage).

Jim H.
------------------------------------------------------------
*start*
01001 00099 US 
gvMsgID: Lampson.PA $ 31#14@11-Aug-83 11:58:09 PDT
Categories: InterScript
Date: Thu, 11 Aug 83 14:57 EDT
From: Lampson.PA
Subject: Interscript status....
To: Ayers, Horning, Mitchell, Paxton, Merry
cc: Lampson, Masinter

What do you think? It sounds like an interesting idea to me.

---------------------------

Date: 30 JUL 83 12:01 PDT
From: MASINTER.PA
Subject: Interscript status....
To:   Lampson
cc:   masinter

I forgot to ask you the other day about the status of Interscript.
When folks ask about Lisp and Star compatibility of documents, we
generally give the stock answer that it will await Interscript.

Perhaps we could get some experience with Lisp/Tioga implementations
as to its usefullness as an interchange mechanism.... (and also
Smalltalk galley editor if they are interested in participating).

Rules might be: you implement from the spec, consultation only
via mail which gets logged?

Larry
------------------------------------------------------------

*start*
00654 00099 US 
gvMsgID: Horning.pa $ 3#203@11-Aug-83 12:18:25 PDT
Categories: InterScript
Date: 11 Aug 83 12:18:23 PDT
From: Horning.pa
Subject: Re: Interscript status....
In-reply-to: "Lampson's message of Thu, 11 Aug 83 14:57 EDT"
To: Lampson
cc: Ayers, Horning, Mitchell, Paxton, Merry, Masinter

I think that we should encourage this. However, since we believe that the draft standard now being completed is precise, but likely to be fully comprehensible only to {Lampson, Ayers, Horning, Mitchell}, perhaps we shouldn't try to hold down the amount of consultation too much. The log could be quite a useful document in its own right.

Jim H.*start*
00377 00098 US 
gvMsgID: Paxton.pa $ 3#211@11-Aug-83 13:39:34 PDT
Categories: InterScript
Date: 11-Aug-83 13:39:33 PDT
From: Paxton.pa
Subject: Re: Interscript status....
In-reply-to: "Lampson's message of Thu, 11 Aug 83 14:57 EDT"
To: Lampson
cc: Ayers, Horning, Mitchell, Merry, Masinter


I'm happy to try it with Tioga2 -- Tioga1 implemenation is frozen.  

--Bill
*start*
00784 00100 US 
gvMsgID: mitchell.pa $ 3#171@12-Aug-83 11:00:25 PDT
Categories: InterScript
Date: 12 Aug 83 10:59:58 PDT
From: mitchell.pa
Subject: Re: Interscript status....
In-reply-to: "Lampson's message of Thu, 11 Aug 83 14:57 EDT"
To: Lampson
cc: Ayers, Horning, Mitchell, Paxton, Merry, Masinter

I think Larry's idea of logging consultations is fine, and I would propose an addition to make it work in the face of (the inevitable) person-to-person conversations: the person who asks a question is responsible for logging both the question and the answer in the mail system.  This is better than expecting the person who answers the question to log the information because it is less centralized; plus, it also checks whether the questioner understood the answer.

--Jim*start*
02596 00101 US 
gvMsgID: PIERCE.DLOS $ 19#130@14-Aug-83 11:25:56 PDT
Categories: InterScript
From: PIERCE.DLOS
Date: 14-Aug-83 13:26:12 CDT
Subject: SGML: The "Logical" Answer?
To: Rowe.pa
cc: DocStandards^.pa

Steve,

ANSI task group 5 (chaired by the loyal opposition from IBM) is strongly pushing for SGML to be the basic methodology for logical structuring to co-exist with layout structures in the developing standards work of ANSI and ISO.

A year ago at one of the Document Standards Committee meetings, Bob Ayers gave a short presentation on some of the shortcomings of GML, the predecessor of SGML.  One of my questions is: Does the current release of SGML (draft release #6- sent to you a day or so ago) correct the deficiencies and is it
now a good "logical" interchange structure that would work well with a layout 
structure?

Larry Tate, the IBM Chairman of TG5, is advocating the use of SGML along with their DCA, which goes under the name of BPTIF(Basic Processable
Text Interchange Format) in ANSI.

Another question is; if SGML is added to DCA (BPTIF) does this 
provide for an interchange format that approaches Interscript in capabilty?  My view is that it falls quite a bit short.

If the marriage of DCA and SGML is "adequate" but not especially a format with entendability or richness, then I think it behooves me as a good citizen of ANSI to point out the deficiencies.  There is a lot of backing for SGML from other standards groups which are closely associated with X3V1 (Office Systems), for instance, X3J6-Computer Languages for Processing Of Text.  They have representatives on X3V1 and they are nodding their heads every time SGML is mentioned.

I would hate to see an "inferior" standard gain wide acceptance, especially when that standard fits hand-in-glove with a major competitor's product line.  This "inferior" standard, if it is fair to call it that, may not allow other vendor's product lines to show their stuff and the printing features that would be available to users would be lost because of lack of standardization.

I have two meetings starting in September that will be dealing specifically with interchange formats and these are crucial meetings at setting general direction.  I would really appreciate your help in bringing this question to resolution so that I can present alternative approaches, or support the present one,  to both
ISO TC97/SC18/WG3 and to ANSI X3V1.

I will be on vacation for a week starting on the 15th, but I have a terminal at my house and I will read my electronic mail and look for your response.

Thanks, 

Roy 
*start*
00776 00099 US 
gvMsgID: Horning.pa $ 3#203@15-Aug-83 10:41:01 PDT
Categories: InterScript
Date: 15 Aug 83 10:40:55 PDT
From: Horning.pa
Subject: Re: SGML: The "Logical" Answer?
In-reply-to: "PIERCE.DLOS's message of 14-Aug-83 13:26:12 CDT"
To: PIERCE.DLOS
cc: Rowe, DocStandards^
Reply-To: Horning.pa

Roy,

I don't see any flaws in your analysis of the situation. In my opinion, the cost to Xerox of allowing a "low capability" standard to become entrenched is far greater than the cost of letting potential competitors see our internal standards. (We don't have to tell them how to IMPLEMENT the standards.)

However, the pessimist/realist in me predicts that Interscript will be treated like Interpress until it is too late to affect the standards process.

Jim H.*start*
01703 00098 US 
gvMsgID: White.pa $ 194#45@15-Aug-83 11:26:31 PDT
Categories: InterScript
Date: 15-Aug-83 11:26:28 PDT (Monday)
From: White.pa
Subject: Re: SGML: The "Logical" Answer?
In-reply-to: PIERCE.DLOS's message of 14-Aug-83 13:26:12 CDT
To: PIERCE.DLOS
cc: Rowe.pa, Elkind, Shoch, Lynch, DocStandards^.pa
Reply-To: White.pa

Roy,  I was with Larry Tate in Austin just a few weeks ago.  Looks like IBM may be about to make the same move in CCITT.

Recommendation S.a is supposed to cover both final-form and revisable-form document formats.  Although the CCITT group has just one more meeting this study period, nothing (!) has been accomplished on the revisable-form format. Ironically, the period responsible for this format is Wolfgang Horack (Siemens).

When I asked what Larry thought the message handling group should do for a simple revisable-form format, he indicated that S.a would have nothing to say about this initially, but that SGML had everything we could possibly need.  Although this suggestion seemed casual at the time, given your information, I wonder if he may not be planning to make a formal pitch for SGML at the final meeting.

Since we currently do no have corporate approval to disclose Interscript and since Xerox is very far indeed from having suitable documentation for Interscript anyway, we are in a difficult position.  However, seems to me that we need immediately a rather thorough understanding, and a written list, of the deficiencies of SGML.

Sounds like if we don't move fast, we'll have lost this one before we know it.

/Jim

P.S.  What does it mean to use SGML "along with" BPTIF?  Would the former be a kind of "subarchitecture" of the latter?
*start*
00928 00099 US 
gvMsgID: Horning.pa $ 3#203@17-Aug-83 17:31:11 PDT
Categories: InterScript
Date: 17 Aug 83 17:31:06 PDT
From: Horning.pa
Subject: Re: SGML: The "Logical" Answer?
In-reply-to: "PIERCE.DLOS's message of 14-Aug-83 13:26:12 CDT"
To: PIERCE.DLOS
cc: White, Hall, Rowe, DocStandards^
Reply-To: Horning.pa

Roy,

Research management is currently very interested in Interpress and Interscript and their relation to external standards. Your comments (and mine) have been forwarded to George Pake, who is requesting prompt senior corporate management action. (However, some of the key people are away for the next couple of weeks.)

Pake asked that I encourage you do everything you can to keep open the option of having our internal standards documents considered by the relevant ANSI and ISO committees. Their capabilities are more important to us than the details of how these capabilities are achieved.

Jim H.*start*
01888 00099 US 
gvMsgID: Horning.pa $ 3#203@22-Aug-83 14:17:54 PDT
Categories: InterScript
Date: 22 Aug 83 14:17:53 PDT
From: Horning.pa
Subject: ANSI/ISO & Interscript
To: Interscript
cc: Hall

-------------------------------------
From: PIERCE.DLOS
Date: 22-Aug-83 15:58:28 CDT
Subject: Re: SGML: The "Logical" Answer?
In-reply-to: Horning.pa's message of 17 Aug 83 17:31:06 PDT
To: Horning.pa
cc: PIERCE

JIM,

I will try to keep ANSI and ISO opportunities open for submission of Xerox internal standards.  The problem I am facing is that many concepts are being finalized, especially because of contributions being submitted by ECMA and other member bodies to ISO.  Fortunately, the ECMA contributions are following the same general path/objectives as Interscript and Xerox contributions should not be too far afield (even belated contributions).

Within ANSI the picture is not as cheerful.  IBM is strongly pushing BPTIF which is in reality their recently released Document Content Architecture
(DCA).  Fortunately the earlier submission of this draft standard was rejected by ISO.  Unfortunately, IBM is "repackaging" BPTIF so as to conform with the general architectural guidelines of ISO and is resubmitting the draft to ISO in September.  At this moment I am not sure if BPTIF has been made "palatable" enough to be accepted by ISO.

I will be meeting with Jack Wheeler, and several other "standards individuals" on August 25 and 26, here in Dallas.  The primary topic will be CCITT activity on message handling but there will be some strategic directions/plans discussed concerning what to do about Interscript and the related work in ANSI and ISO.  By the end of the week I should have a better idea of how to put forth Xerox strategies at the upcoming X3V1 and ISO meetings.

I will keep you posted.

Roy

------------------------------------------------------------
*start*
01444 00100 US 
gvMsgID: Mulhern.PA $ 20#117@25-Aug-83 17:15:54 PDT
Categories: InterScript
Date: Thu, 25 Aug 83 17:15 PDT
Subject: Adams Appointed Chairman, Systems Board
To: TodayAtXerox^.PA
From: Today At Xerox <Mulhern.PA>
Reply-To: Mulhern.PA


TODAY AT XEROX					NO. 747
							August 25, 1983

ADAMS APPOINTED CHAIRMAN, SYSTEMS BOARD

Robert V. Adams, group vice president and president of the Systems Group, has been appointed chairman of the Xerox Systems Integration Standards Board (SISB), succeeding John V. Titsworth, who recently retired.  J.I. Elkind, vice president, Systems Integration and Software Strategy, XSG, will continue as secretary of the SISB.  The membership of the SISB consists of senior managers from Systems Group divisions, Research and Corporate Staff who are most directly concerned with our systems business.

The SISB is responsible for Xerox' systems integration strategy and for ensuring that present and future Xerox products and selected products from other vendors can be integrated to provide customers with systems that operate in a consistent and coherent way.  The SISB has established subcommittees to develop the standards that are the basis for the integration of our products.

It has also established the Network Systems Integration Committee to expedite the implementation of these standards in present and future products, and to coordinate product planning and support procedures.

*start*
00324 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 7-Sep-83 19:19:33 PDT
Categories: InterScript
Date:  7 Sep 83 19:19:29 PDT (Wednesday)
From: Ayers.PA
Subject: Friday Meeting
To: Mitchell

My Friday pm meeting was postponed a week, so I will set aside Friday afternoon to get together with you as your shedule permits ...
*start*
00394 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 8-Sep-83  9:30:55 PDT
Categories: InterScript
Date:  8 Sep 83  9:30:43 PDT
From: mitchell.pa
Subject: Re: Friday Meeting
In-reply-to: "Your message of 7 Sep 83 19:19:29 PDT (Wednesday)"
To: Ayers
cc: Mitchell

Roger on Friday afternoon.  I will give you a call as soon as I am free.  ETEM (Estimated Time End of Meeting) is 2:30 pm.

--Jim
*start*
00301 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 8-Sep-83 10:05:32 PDT
Categories: InterScript
Date:  8 Sep 83 10:05:30 PDT (Thursday)
From: Ayers.PA
Subject: Elkind and Deadlines ...
To: Mitchell

I talked to Jerry last evening and said "Interscript Draft Tuesday."

He said "Next Tuesday? Fine."

*start*
00518 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Sep-83 17:24:05 PDT
Categories: InterScript
Date: 10 Sep 83 17:23:57 PDT (Saturday)
From: Ayers.PA
Subject: Section 3 page 15
To: Mitchell
cc: Ayers

I do not understand the organization of this.

For example, the text on page 15 repeatedly uses the phrase "Bool^".  I 
do not see "Bool^" defined anywhere.

Bob

PS: I was trying to figure out how to say that an attribute had to have a value of an array of Foo nodes.  I couldn't find out how to say that, either.
*start*
00428 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Sep-83 20:38:27 PDT
Categories: InterScript
Date: 10 Sep 83 20:38:19 PDT (Saturday)
From: Ayers.PA
Subject: Looping in Interscript
To: Mitchell, Horning
cc: Ayers

I am trying to write the "reducesTo" for paragraph&line that incluudes tabs.

The problem is that I need to introduce "n" box nodes, where "n" is the number of defined tab stops.

I don't se any way to do this.
*start*
00312 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Sep-83 20:39:05 PDT
Categories: InterScript
Date: 10 Sep 83 20:38:58 PDT (Saturday)
From: Ayers.PA
Subject: IFs in Interscript
To: Mitchell
cc: Ayers

The IF statement was in the original proposal.  Did it go away?  I do not se it in the current section two.
*start*
00899 00100 US 
gvMsgID: mitchell.pa $ 3#171@11-Sep-83 23:35:28 PDT
Categories: InterScript
Date: 11 Sep 83 23:35:14 PDT
From: mitchell.pa
Subject: Re: IFs in Interscript
In-reply-to: "Your message of 10 Sep 83 20:38:58 PDT (Saturday)"
To: Ayers
cc: Mitchell

The IF statement was taken out in favor of subscripted nodes.  

IF boolExp THEN exp1 ELSE exp2 becomes {exp2 exp1}(boolExp) because boolExp will have either the value 0 (false) or 1 (true)


This plus recursive use of quoted expressions should also be able to solve your n boxes problem.

Re section 3, p. 15.  I forgot to put some the type definition for Bool in the place where I defined Any, AtomList, None, and Predicate.

To say that an attribute has to have a value which is an array of Foo nodes, we will have to define a type Vector with attributes size and elementType.  I will add it to section three I guess.

--Jim M. *start*
00602 00097 US 
gvMsgID: Ayers.PA $ 60#91@12-Sep-83 11:01:01 PDT
Categories: InterScript
Date: 12 Sep 83 11:00:55 PDT (Monday)
From: Ayers.PA
Subject: Fixing Box Metrics if they are given as a variable MEASURE
To: Mitchell, Horning, Lampson
cc: Ayers

The current Layout discussion does not handle one case:

  A box's metrics are given as non-fixed MEASUREs.
  The box has no descendants and thus no "layout proceeds" binding.
  
This is because the algorithm in FixMeasuresXorY assumes that leaf-boxes do not need to have anything done to them.

I propose to fix this, but not today ...

Bob
*start*
01018 00097 US 
gvMsgID: Ayers.PA $ 60#91@14-Sep-83 15:04:42 PDT
Categories: InterScript
Date: 14 Sep 83 15:04:40 PDT (Wednesday)
From: Ayers.PA
Subject: Seminars on draft Interscript Standard
To: SDD-AD-PA^
cc: SDD-SS-PA^, SDD-WSS-PA^, SDD-SVS-PA^
cc: (fyi) Mitchell, Horning

I propose to hold seminars to discuss the draft Interscript Standard, especially on how Interscript relates to AD activities.

These will NOT be crosstalk-like overview sessions, but will assume that participants have read the draft Interscript Standard and have concerns about how Interscript relates to some project or venture that they are currently engaged in or actively planning. Participants will be expected to be active: this is not a lecture series.  

The seminars will be held at Bayhill on Tuesdays from 2pm to 4pm, and will run until interest tails off. 

If you would like to participate, reply to this message and I will supply you with a copy of the draft Standard and discuss your interest in Interscript.

Bob   
*start*
00439 00099 US 
gvMsgID: Horning.pa $ 3#203@14-Sep-83 15:39:28 PDT
Categories: InterScript
Date: 14 Sep 83 15:39:26 PDT
From: Horning.pa
Subject: Re: Seminars on draft Interscript Standard
In-reply-to: "Ayers' message of 14 Sep 83 15:04:40 PDT (Wednesday)"
To: Ayers
cc: Mitchell, Horning

Bob,

I'd be happy to sit in on these and try to help move the discussion along. I'll be travelling for the next two weeks, however.

Jim H.
*start*
00409 00100 US 
gvMsgID: mitchell.pa $ 3#171@14-Sep-83 16:53:30 PDT
Categories: InterScript
Date: 14 Sep 83 16:53:21 PDT
From: mitchell.pa
Subject: Re: Seminars on draft Interscript Standard
In-reply-to: "Ayers' message of 14 Sep 83 15:04:40 PDT (Wednesday)"
To: Ayers
cc:  Mitchell, Horning

Bob,

I will try to come to as many of these as I can.  When do you expect to hold the first one?

--Jim M.
*start*
00785 00098 US 
gvMsgID: Paxton.pa $ 3#211@23-Sep-83 17:07:32 PDT
Categories: InterScript
Date: 23-Sep-83 17:07:40 PDT
From: Paxton.pa
Subject: Interscript
To: Mitchell, Ayers

Jim & Bob,

I've received a copy of the draft standard and am working my way through it.  Looks good, but I need an informal statement of the semantics before I'm willing to plow through the formal Cedar semantics.  One sentence or so with each construct of the concrete grammar would do the trick nicely.  Trying to figure out the difference between binding and sBinding, for example, by studying the formal semantics is just too difficult.  If you or Butler or Jim produces such a set of comments, please forward them to me.  I'd like to understand the semantics before going further.

Thanks, Bill*start*
01493 00101 US 
gvMsgID: pierce.dlos $ 19#130@30-Sep-83 14:18:29 PDT
Categories: InterScript
From: pierce.dlos
Date: 30-Sep-83 16:18:06 CDT
Subject: Layout Objects-ISO WG5 Positions
To: Rowe.pa
cc: Ayers.pa,Mitchell.pa,Wheeler.wbst,ESmura.es


Steve,

A recent ISO WG5 document (N130) identifies a layout structure composed of
a hierarchy of three objects: nominal page, frame, and text block.  Nominal page is at the highest level and text block is at the lowest.

Similar concepts appear in the current drafts of CCITT's S.a and ECMA TC 29
papers.  A difference in the CCITT and ECMA papers that cause concern
to ISO WG5 is the overlapping of these text layout objects and the fact that
these layout objects may have attributes of "transparency" or "opaqueness" for resolving the image in the overlaid area.

A WG5 comment is, "WG5 is still concerned that the image processing capability
required in a text preparation and interchange system, for the combination of overlaid text blocks and overlaid frames is so great that the implementation complexity may outweigh the usefulness of the concept."

WG5 goes on to request contributions from member bodies (individuals too, I 
assume) dealing with the implications of permitting or restricting any 
overlapping of frames.

Would this be a good opportunity to present any of the layout techniques
(boxes) of Interscript?  This is a place where a short "research" type 
paper would be welcome.

Let me know your feelings on this.

Roy
*start*
01190 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 7-Oct-83 15:37:28 PDT
Categories: InterScript
Date:  7 Oct 83 15:37:31 PDT
From: mitchell.pa
Subject: Memo of Understanding for Interscript
To: ALBrown, Elkind
Cc: mitchell, Schroeder

Here is my proposal for a Memo of Understanding from OSD/SDD for Interscript:
----------------------
OSD expects to pursue the implementation of the document interchange standard being developed by the Document Interchange Subcommittee of the Systems Integration and Standards Board.  Since Interscript is the only proposal being actively considered by that subcommittee, OSD plans to implement Interscript in the context of the publishing project to test and debug Interscript.  If that experiment is successful and Interscript is accepted as a corporate standard, OSD will use it to make the PICS product an Interscript-conforming editing system.

----------------------

Please feel free to alter this to make the language acceptable to you.  Mike Schroeder has informed me that he needs an official version of this by Monday, October 17.

Thanks,

--Jim Mitchell


�ÊK˜Jš
œ˜Jš
œ˜JšÐbsœ'˜.Jš�œ˜Jš�œ˜J˜J˜ä—…—òC*start*
02812 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Oct-83 10:58:52 PDT
Categories: InterScript
Date: 10 Oct 83 10:58:54 PDT (Monday)
From: Ayers.PA
Subject: Palandri Missive
To: Rowe
cc: Horning, Mitchell, Lampson, Ayers

    [Steve, how formal a reply do you want? Looks to me like Palandri 
     is trying to cover himself ...]

Steve, ever since the Interscript project was begun, there have been two groups: the Technical Working Group and the Document Interchange Subcommittee.

The latter group (your group, formerly Irby's group) met for the first time on 21 January 1982 to discuss both the initial proposals of the Technical Working Group and the business needs of the Xerox community.

Looking at Irby's minutes of that meeting I see:

    Wendell Schultz was present as PSD's representative.
  
    Additionally, the minutes went to Pete England and Mike Townsend.
  
    From the minutes:
  
       "5. The subcommittee approved the technical direction of the
        working group which recommends the Interdoc approach to
        Document Interchange Standards. It was recommended that all 
        future editing systems should output/accept Interdoc unless 
        given explicit approval to deviate by the SISB. Existing prodcts 
        are to be handled on a case-by-case basis."
      
    From the minutes:
  
       "PSD's interest in Interdoc is with respect to XICS, GCS and
        similar Composition products that allow customers to create 
        production masters. The Interdoc standard will be supported 
        by PSD as it will simplify the product functions and the need 
        for multiple convesions."
      
    
I believe that Mr. Palandri is mis-informed as to the nature of Interscript. From his memo, it appears that he believes that Interscript was designed to be a lingua franca for EXISTING Xerox product programs and their document formats. 

This is not the case. Although Interscript will aid the "m*n conversion" problem, it was designed with new programs in mind.  The way you get an Interscript-accepting editor is to design&write an editor.  "Existing prodcts are to be handled on a case-by-case basis."


It appears from the minutes of the January 1982 meeting that PSD/XICS were fully aware of the nature of the proposed standard, and that they were interested in supporting it. 


It is true that the Technical Working Group did not completely familiarize themselves with the XICS markup language; we did familiarize ourselves with the IBM "GML" markup language and with the X3J6 markup language standardization effort. 


Since "the subcommittee approved the technical direction of the working group which recommends the Interdoc approach to Document Interchange Standards" I am a little surprised at these late comments from Mr. Palandri.

Bob
    
*start*
00373 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Oct-83 16:30:20 PDT
Categories: InterScript
Date: 10 Oct 83 16:30:22 PDT (Monday)
From: Ayers.PA
Subject: Re: Interscript Seminar Tuesdays?
In-reply-to: Horning's message of 10 Oct 83 16:09:54 PDT
To: Horning
cc: Mitchell

We plan on running this series on Tuesdays. The first Tuesday will be at least 14 days from now.
*start*
01693 00099 US 
gvMsgID: ALBrown.PA $ 60#18@11-Oct-83  9:13:21 PDT
Categories: InterScript
Date: 11 Oct 83 09:13:24 PDT (Tuesday)
From: ALBrown.PA
Subject: Re: Memo of Understanding for Interscript
In-reply-to: mitchell's message of 7 Oct 83 15:37:31 PDT
To: Mitchell
cc: Ayers, ALBrown, Elkind, Rowe, Schroeder

Jim,

Here's my rework of the memorandum of understanding for Interscript.  The finality of this draft will presumably be determined by Jerry Elkind.

----------------------

OSD is pursuing implementations of the document interchange standard being developed by the Document Interchange Subcommittee of the Systems Integration and Standards Board.  Since Interscript is the only proposal being actively considered by the subcommittee as the Xerox-wide interchange standard, OSD is implementing two Interscript editors, motivated, in part, by the desire to validate the standard as an interchange medium.  One editor is being developed by the Publishing Systems Development group; the other will be done as an Advanced Development project.  The success of these implementations will presumably serve as support for the adoption of the standard.

The other (independent) motivation in developing Interscript based editors stems from the fact that the Publishing Systems program requires a model of documents that is sufficiently expressive to accomdate the complexity that is common in publication quality documents, and that is sufficiently extensible to capture document structures that might appear in future versions of the publishing system.  As Interscript seems to fit these needs, it is the model of choice for the publishing editor.

----------------------

Allen
*start*
03075 00096 US 
gvMsgID: Suk.PA $ 194#50@11-Oct-83 16:36:59 PDT
Categories: InterScript
Sender: Suk.PA
Date: 11 Oct 83 16:37:12 PDT (Tuesday)
Subject: New Standards Documents
To: OSBU^.es, CommunicationProtocols^.pa, CourierInterest^.pa, DocStandards^.pa, DocumentInterchange^.pa, IPDesign^.pa, IPImpl^.pa, IPImplementors^.es, IPInterest^.pa, NetStandards^.wbst, NPA^.wbst, PrintingProtocolDesign^.es, PrintingProtocolImplementors^.es,  PrintingProtocolInterest^.es, PrintServiceInterest^.es, ScanStandards^.wbst, ServicesImplementors^.es, ServicesInterest^.es
To: L Bond ESDS A1-65<ESMail.es>,  P England ESCP P3-16<ESMail.es>,     A Lipton ESDS M1-16<ESMail.es>,     T Ogi ESDS A3-55<ESMail.es>, M A Henderson DLOS 199<ESMail.es>, C Jacobson DLOS 129/550<ESMail.es>, R Pierce DLOS 625A<ESMail.es>,      N Reed DLOS 185<ESMail.es>,    W Swanstrom DLOS 185<ESMail.es>, R Vance DLOS 134<ESMail.es>, L Van Gunten HADB FM227<ESMail.es>,      W White HADB F111<ESMail.es>, J Woolbright HADB FM227<ESMail.es>
To: R Boehner WBST 129<MCMail.wbst>,  C Holt WBST 129<MCMail.wbst>,   P Lavallee WBST 128<MCMail.wbst>,     D Wilkie TOHQ 6800<MCMail.wbst>
To: Blake.RX, Sproull@CMU-CS-VLSI.ARPA
To: K Oikawa<FXMail.fx>
To: R Stern<Kurzweil>
cc: ExtStds^.wbst, Drosdek.wbst, Library, Murphy, Warner
From: OSD Technical Publications <OSD-Pubs.pa>
Reply-To: OSD-Pubs.pa


This is to announce the availability of two new standards documents.  The protocol standards described in these documents have been approved by the System Integration Standards Board (SISB) and are now Xerox Corporate Standards.  For the time being, these documents are all Xerox Private Data, and should be circulated within the company on a NEED-TO-KNOW basis only.

The following documents are now available:

	   Title			   Date		  Pub. No.

Clearinghouse Protocol			August, 1983	XSIS 078308
Interpress Electronic Printing Std	June, 1983	XSIS 048306


CLEARINGHOUSE PROTOCOL:

If you are a full-time permanent Xerox employee, you may request a copy of the Clearinghouse Protocol standard by sending a message to <OSD-Pubs.pa>, or by phoning Suzi Winch at 8*923-5886.  If you are a part-time or contract employee and need this document in your work, please have your Xerox supervisor make the request.  If you are located somewhere other than Palo Alto, please supply both your internal mail stop number and your external (USPS) mailing address.


INTERPRESS STANDARD:

This is a new version, revised from the "Interpress 82" document that was released approximately 18 months ago.  Your source for this document depends upon your location: if you work in northern California, order as above; if you are located anywhere BUT Northern California, order from Jerry <Mendelson.es>, 8*823-9520.

Please remember that anything associated with Interpress is to be held strictly within Xerox.  Single copies are available to Xerox employees only.  It takes the personal approval of Bob Adams, together with a signed non-disclosure agreement, before any Interpress information may be disseminated outside of Xerox.
*start*
01143 00099 US 
gvMsgID: Horning.pa $ 3#203@17-Oct-83 11:52:16 PDT
Categories: InterScript
Date: 17 Oct 83 11:52:05 PDT
From: Horning.pa
Subject: Re: Palandri memo of Oct. 4
To: Rowe
cc: Mitchell, Ayers, Horning, Lampson, Paxton

Steve,

Due to the wonders of interoffice mail, your memo of Oct. 10, requesting comments on Mark's memo of Oct. 4, reached me this morning.

I'm not quite sure how to react. Mark seems quite unaware that his second concern directly contradicts his first concern (that Interscript is designed only for WYIWYG editors). He seems as ignorant of Interscript as I am of XICS; the fact that extensibility has been a major design goal of Interscript throughout seems to have escaped his notice.

I suppose that it is important to be polite to him--I trust that you're better at this than I. I don't see any really tactful way to say that Interscript was designed considering state-of-the-art batch composition systems (Scribe and TEX), and that we have had no reason to suspect that XICS would raise any new issues.

Jim H.
�ÊQ˜JšÏsœ˜Jš�œ˜Jš�œ˜$Jš�œ˜Jš�œ*˜-J˜J˜ªJ˜—…—¾*start*
01591 00106 US 
gvMsgID: Schwarcz.Siemens $ 194#64@26-Oct-83  9:24:33 PDT
Categories: InterScript
Date: 26 Oct 83 09:24:35 PDT (Wednesday)
From: Schwarcz.Siemens
Subject: Siemens Visitor Re: Interscript
To: Mitchell.pa, Ayers.pa
cc: Elkind.pa, Shoch.pa, English.pa, Rowe.pa
cc: Schwarcz.Siemens

Messers Mitchell and Ayers,

Siemens would like to send Herr Horak, a member of the Central Corporate Division for Research and Development who is the responsible expert of the Document Interchange Standards Committee, to Palo Alto to discuss the draft Interscript document with you. He can arrange to spend 2 December (Friday) or 5 December (Monday) with you. 

Herr Horak is not interesting in "formal" presentations but rather in discussing

1) some technical aspects of the draft standard 

2) the possibility of Siemens accepting Interscript as its corporate document interchange standard (probably depends on how good it is and -- importantly -- how fast it can be implemented)

3) the ways and means in which Siemens might be able to cooperate in implementing Interscript (e.g. send a person to Palo Alto, do something in Munich ...)

Steve Rowe and I have discussed this and agree that the most profitable use of time would be to have Herr Horak meet with you to discuss technical questions first. Naturally the results of this discussion will have impact on points 2) and 3) above. 

Are either (or both) of these days acceptable to you? Do each or both of you have a preference?  Please reply to me, I'll set up the rest of the schedule accordingly.

Thomas (Schwarcz.Siemens)
*start*
03008 00097 US 
gvMsgID: Banks.pa $ 194#8@26-Oct-83  9:36:48 PDT
Categories: InterScript
Sender: Banks.pa
Date: 26 Oct 83 09:37:13 PDT (Wednesday)
Subject: Document Interchange
To: Elkind.pa
From: Rowe.pa
cc: Rabinovitch.pa, Bhushan.WBST, Mitchell.pa, Pierce.dlos, Ayers.pa, Horning.pa, Lampson.pa, ALBrown.pa, Bulnes.pa, JWeaver.pa, Banks

Jerry,  Many thanks for your words of encouragement:  we have a good team!

In response to your note I offer the following recommendations.


1)	The authoring of the draft Interscript technical specification should be completed as soon as possible by Bob Ayers and Jim Mitchell (I understand that Bob and Jim are agreeable to do this.  Would Bob & Jim please estimate when they expect the job will be done.)

2)	An Introduction/Implementor's Guide to Interscript needs to be written (roughly equivalent to the job performed by Sproull on Interpress).  The writer of this document should be simultaneously involved with the technical development of the PICS Interscript editor (a trial implementation).  This individual would divide his time equally between technical development and generation of the document.  He would be under Bob Ayers' general supervision.  Target date for completion is Dec 1984.

3)	Simultaneously with the PICS trial implementation I understand parallel implementations are to be planned by PARC (TIOGA?) and SDD Advanced Development (820).

4)	A competent technical writer needs to be assigned to edit and publish "(1)" and "(2)".  This person should be part of your standards organization.  I imagine the forthcoming scanned image standards will require similar attention.  Lee Knudsen would be very interested in discussing this sort of assignment for 1984.  I have spoken to Mary Kaye Fenwick (Lee's boss) on this topic and there may be a problem in having Lee transfer to our standards activity.  I will bring John Hotchkiss into this discussion.

5)	I have asked Roy Pierce to work up a plan with Bob Ayers and Jim Mitchell for the orderly release of sound principles for Document Interchange to the relevant ISO/ANSI committees.  I am ready to help if needed.


Jerry, I am looking to you for the 1984 funding of the following activities:


Introduction/Implementor's Guide	0.5 MY
Complete Interscript draft spec		0.5 MY
Technical writing and publishing	1.0 MY
of the above

I estimate that the fully loaded expense for this would be $150K in 1984.

I have spoken with Issie on this and he feels that no funds would be available from OSD.  He has asked that you approach Bob Adams for the funding of what looks like a general XSG need.

On a related matter I responded to Joel Kruissink of Xerox Seattle; concerning Boeing  inquiries raised at our September 16 meeting:

1)	CPD will market post processors enabling 2700 and 9700 printing of DCF documents, within the next three months.

2)	CPD plan to offer printing of DCA documents "sometime".

3)	For futher information I referred Joel to Ron Richter at El Segundo.


Steve
*start*
00643 00100 US 
gvMsgID: mitchell.pa $ 3#171@26-Oct-83 10:18:32 PDT
Categories: InterScript
Date: 26 Oct 83 10:18:21 PDT
From: mitchell.pa
Subject: Re: Interscript
In-reply-to: "Schwarcz.Siemens's message of 26 Oct 83 09:24:35 PDT (Wednesday)"
To: Schwarcz.Siemens
Cc: Mitchell, Ayers, Elkind, Shoch, English, Rowe

I would prefer Friday, December 2 to meet with Herr Horak.  I look forward to talking with him as I found the document that he and Herr Kronoert wrote parallels much of our early thinking on document interchange.

--Jim Mitchell
�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ˜Jš�œD˜OJš�œ˜Jš�œ/˜1J˜J˜ä
—…—
Æ *start*
00491 00097 US 
gvMsgID: Ayers.PA $ 60#91@26-Oct-83 11:43:40 PDT
Categories: InterScript
Date: 26 Oct 83 11:40:50 PDT (Wednesday)
From: Ayers.PA
Subject: Re: Siemens Visitor Re: Interscript
In-reply-to: Schwarcz.Siemens's message (and Mitchell's reply)
To: Schwarcz.Siemens
cc: Mitchell, Ayers, Elkind, Shoch, English, Rowe

Sounds like an excellent opportunity for both us and Siemens.  I echo Mitchell's interest and look forward to meeting with Herr Horak on Friday 2 December.  
*start*
01370 00099 US 
gvMsgID: Linden.PA $ 194#38@31-Oct-83 11:35:34 PST
Categories: InterScript
Date: 31 Oct 83 11:31:09 PST (Monday)
From: Linden.PA
Subject: Boeing trip Nov 30 - Dec. 1
In-reply-to: Elkind's message of Thu, 13 Oct 83 13:00 PDT
To: Elkind, Horning, Garlick
cc: Mitchell, Linden, Rabinovitch, Murphy

I have finally managed to get through to Jim Flexer at Boeing about setting up the meeting there to speak to their Network Architecture group and get the official proclamation from them that we are compatible with Boeing's long term network architecture and standards.

He claims it only needs to be a 1 day meeting--either the 30th or 1st.  At this point, he has no preference, but that may change.  I gather the plans are for Jerry, Larry, I and maybe Jim (Horning or Mitchell) to go.  Jerry, do you know if they need an Interscript presentation at this meeting?  If you don't know, I will pursue it.

While we are up there, Jerry, do we also want to make progress on plans for them implementing products that use our protocols.  I believe this is a different topic.  JERRY, I ASSUME YOU ARE HANDLING ANY ARRANGEMENTS IN THIS AREA, as I have my plate too full at this time developing other higher priority agreements with other companies.  I can help while I'm up there, but am not yet ready to dig into Boeing contract negotiations in any depth. 
*start*
01028 00097 US 
gvMsgID: Ayers.PA $ 60#91@31-Oct-83 16:37:43 PST
Categories: InterScript
Sender: Ayers.PA
Date: 31 Oct 83 16:38:04 PST (Monday)
Subject: Introductory Talk on Interscript Standard
To: SDD^, ComputerResearch^, Methodology^, DocumentInterchange^, OSBU-Planning^
cc: Mitchell, Ayers, Lampson, Horning
cc: Shoch, Rowe  
From: Mitchell, Ayers
Reply-to: Mitchell, Ayers

The "Interscript Standard" is a proposed, evolving standard for the exchange of editable documents among editing systems. 

The draft standard was created over the past two years by a group of designers from OSD and PARC. It is currently being "debugged" in several projects and product programs, and will, in due course, be presented to the Xerox Systems Integration and Standards Board.

An introductory "overview" of the Draft Standard will be presented:

      Bayhill Building, 200M
    
      2:00pm - 4:00pm, Tuesday 8 November
    
Jim and Bob

PS: We plan on video-taping this talk for the out-of-towners and couldn't-make-it-ers.
*start*
00437 00101 US 
gvMsgID: Schwartz.RX $ 100#11@ 1-Nov-83  4:02:39 PST
Categories: InterScript
Date:  1 Nov 83 05:52:46 GMT (Tuesday)
From: Schwartz.RX
Subject: Re: Introductory Talk on Interscript Standard
In-reply-to: Ayers.PA's message of 31 Oct 83 16:38:04 PST (Monday)
To: Mitchell.PA, Ayers.PA
cc: Schwartz

Gents,

Could you please arrange to send a copy of the videotape to those of us in SDD/Welwyn Hall?

Cheers!

Victor
*start*
00538 00101 US 
gvMsgID: HAINS.PASA $ 135#140@ 1-Nov-83  8:13:08 PST
Categories: InterScript
Date:  1 Nov 83 08:12:59 PST (Tuesday)
From: HAINS.PASA
Subject: Re: Introductory Talk on Interscript Standard
In-reply-to: Ayers.PA's message of 31 Oct 83 16:38:04 PST (Monday)
To: Mitchell.PA, Ayers.PA
cc: HAINS, Suggs,Marlett

Please include XSIS in the distribution of the videotape of the Introductory Talk on Interscript Standard to be given on Tuesday 8 November.

Send to Chuck Hains, XSIS Pasadena m/s 359
Thank you,
			chuck


*start*
00505 00100 US 
gvMsgID: DeSantis.ES $ 65#21@ 2-Nov-83 11:17:38 PST
Categories: InterScript
Date:  2 Nov 83 11:18:47 PST (Wednesday)
From: DeSantis.ES
Subject: Re: Introductory Talk on Interscript Standard
In-reply-to: Ayers.PA's message of 31 Oct 83 16:38:04 PST (Monday)
To: Mitchell.PA, Ayers.PA
cc: Finkel, DeSantis

Jim & Bob,

Workstation Software will be sending Steve Finkel, Rex Walden and Bruce Lee to the Introductory Talk on Interscript Standard.  Thanks for holding the session.

Dan
*start*
00592 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 2-Nov-83 15:52:22 PST
Categories: InterScript
Date:  2 Nov 83 15:52:26 PST
From: mitchell.pa
Subject: FYI Taping Interscript seminar
To: Ayers
Cc: mitchell

Bob,
I have made arrangements to video-tape the Interscript seminar on Tuesday.  When I come over to see you tomorrow at 1:00, I will bring a purchase requisition for you to sign.  I also extended the room reservation back to 12:00 to give them more time to set up.  It seems under control.

--Jim

�ÊK˜Jš
œ˜Jš
œ˜JšÐbsœ!˜(Jš�œ˜	Jš�œ
˜J˜J˜ª—…—
œ
í*start*
01193 00098 US 
gvMsgID: Murphy.PA $ 48#26@ 4-Nov-83 12:29:26 PST
Categories: InterScript
Date: Fri, 4 Nov 83 12:29 PST
From: Murphy.PA
Subject: Re: Boeing trip Nov 30 - Dec. 1
In-reply-to: "Linden's message of 31 Oct 83 11:31:09 PST (Monday)"
To: Linden
cc: Elkind, Horning, Garlick, Mitchell, Rabinovitch, Murphy

Ted,

As you suggested, I contacted Ken Larsen, the NAM for Boeing, and told him that Jerry had to be in Munich 11/29 and 11/30. He contacted Boeing and they decided on 12/8 and 12/9 for the meeting.  The network architecture portion of the meeting (coordinated by Flexer) is scheduled for half a day on the 8th, the rest of the meeting (?) is coordinated by Martin Ritchie and is scheduled for the 9th. 

I suggested someone set up a tentative agenda so we could see what was planned.  Ken said he would ask Flexer and Ritchie to write down their objectives and send them to us as soon as possible.

Jerry says yes, they do want an Interscript presentation.  I will remind him about your question on plans for them implementing products that use our protocols.

I hope to get more information on this next week, but wanted to let you know where it stands now.

Jan  

*start*
00448 00101 US 
gvMsgID: Suggs.pasa $ 135#145@ 7-Nov-83  9:15:38 PST
Categories: InterScript
Date:  7 Nov 83 09:15:31 PST (Monday)
From: Suggs.pasa
Subject: Re: Introductory Talk on Interscript Standard
To: Mitchell.PA, Ayers.PA
cc: , Suggs.pasa

We would like to send a representative from XSIS to hear the  Introductory Talk on Interscript Standard to be given tomorrow. Can you tell me when and where the meeting will be?

Thanx

Marian
*start*
01601 00099 US 
gvMsgID: Linden.PA $ 194#38@ 7-Nov-83 10:34:22 PST
Categories: InterScript
Date:  7 Nov 83 10:29:13 PST (Monday)
From: Linden.PA
Subject: Interpress presentation at Boeing 12/8
To: Horning, Mitchell
cc: Linden, Murphy, Elkind

I believe this is a request for one of you to come up to Seattle for this new date.  Please talk to Jerry with questions. 

----------------------------------------------------------------
Date: Fri, 4 Nov 83 12:29 PST
From: Murphy.PA
Subject: Re: Boeing trip Nov 30 - Dec. 1
In-reply-to: "Linden's message of 31 Oct 83 11:31:09 PST (Monday)"
To: Linden
cc: Elkind, Horning, Garlick, Mitchell, Rabinovitch, Murphy

Ted,

As you suggested, I contacted Ken Larsen, the NAM for Boeing, and told him that Jerry had to be in Munich 11/29 and 11/30. He contacted Boeing and they decided on 12/8 and 12/9 for the meeting.  The network architecture portion of the meeting (coordinated by Flexer) is scheduled for half a day on the 8th, the rest of the meeting (?) is coordinated by Martin Ritchie and is scheduled for the 9th. 

I suggested someone set up a tentative agenda so we could see what was planned.  Ken said he would ask Flexer and Ritchie to write down their objectives and send them to us as soon as possible.

Jerry says yes, they do want an Interscript presentation.  I will remind him about your question on plans for them implementing products that use our protocols.

I hope to get more information on this next week, but wanted to let you know where it stands now.

Jan  


----------------------------------------------------------------
*start*
01409 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 7-Nov-83 11:37:34 PST
Categories: InterScript
Date:  7 Nov 83 11:37:42 PST
From: mitchell.pa
Subject: Re: Introductory Talk on Interscript Standard
In-reply-to: "Suggs.pasa's message of 7 Nov 83 09:15:31 PST (Monday)"
To: Suggs.pasa
Cc: Mitchell, Ayers

Here is the original announcement for the Introductory Talk on Interscript:

Sender: Ayers.PA
Date: 31 Oct 83 16:38:04 PST (Monday)
Subject: Introductory Talk on Interscript Standard
To: SDD^, ComputerResearch^, Methodology^, DocumentInterchange^, OSBU-Planning^
cc: Mitchell, Ayers, Lampson, Horning
cc: Shoch, Rowe  
From: Mitchell, Ayers
Reply-to: Mitchell, Ayers

The "Interscript Standard" is a proposed, evolving standard for the exchange of editable documents among editing systems. 

The draft standard was created over the past two years by a group of designers from OSD and PARC. It is currently being "debugged" in several projects and product programs, and will, in due course, be presented to the Xerox Systems Integration and Standards Board.

An introductory "overview" of the Draft Standard will be presented:

      Bayhill Building, 200M
    
      2:00pm - 4:00pm, Tuesday 8 November
    
Jim and Bob

PS: We plan on video-taping this talk for the out-of-towners and couldn't-make-it-ers.


�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ/˜6Jš�œ:˜EJš�œ˜Jš�œ˜J˜J˜ñ—…—Ä*start*
01344 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 7-Nov-83 15:49:24 PST
Categories: InterScript
Sender: Ayers.PA
Date:  7 Nov 83 15:49:42 PST (Monday)
Subject: NEW PLACE: Introductory Talk on Interscript Standard
To: SDD^, ComputerResearch^, Methodology^, DocumentInterchange^, OSBU-Planning^
cc: Mitchell, Ayers, Lampson, Horning
cc: Shoch, Rowe  
From: Mitchell, Ayers
Reply-to: Mitchell, Ayers

[We have moved the talk to the PARC Auditorium, as feedback from the original announcement indicates that the audience may be larger than 200M will hold.  We have slipped the time by 15 minutes so that people who do not receive this message will be able to forward themselves from 200M to the auditorium ...]


The "Interscript Standard" is a proposed, evolving standard for the exchange of editable documents among editing systems. 

The draft standard was created over the past two years by a group of designers from OSD and PARC. It is currently being "debugged" in several projects and product programs, and will, in due course, be presented to the Xerox Systems Integration and Standards Board.

An introductory "overview" of the Draft Standard will be presented:

      PARC Auditorium
    
      2:15pm - 4:15pm, Tuesday 8 November
    
Jim and Bob

PS: We plan on video-taping this talk for the out-of-towners and couldn't-make-it-ers.

*start*
00541 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 7-Nov-83 17:52:47 PST
Categories: InterScript
Date:  7 Nov 83 17:52:54 PST
From: mitchell.pa
Subject: Re: Interpress presentation at Boeing 12/8
In-reply-to: "Linden's message of 7 Nov 83 10:29:13 PST (Monday)"
To: Linden
Cc: Horning, Mitchell, Murphy, Elkind

I would be willing to go on this trip, but it seems to me that Bob Ayers would be a better candidate.  Has anyone asked him?

--Jim M.

�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ,˜3Jš�œ6˜AJš�œ˜
Jš�œ#˜%J˜J˜‡
—…—
`
º*start*
00501 00099 US 
gvMsgID: talbot.rx $ 100#18@ 8-Nov-83  0:49:52 PST
Categories: InterScript
Date:  8 Nov 83 08:45:33 GMT (Tuesday)
From: talbot.rx
Subject: Re: NEW PLACE: Introductory Talk on Interscript Standard
In-reply-to: Ayers.PA's message of 7 Nov 83 15:49:42 PST (Monday)
To: Mitchell.PA, Ayers.PA,INSSTAFF^.rx,Bittner.pa
cc: talbot.rx
Reply-To: talbot.rx

Gents,

we would be interested in the Video on the above.  Could you arrange for Alice to send a copy, she knows the ropes.

John
*start*
00875 00101 US 
gvMsgID: Schwartz.rx $ 100#11@ 8-Nov-83  0:53:39 PST
Categories: InterScript
Date:  8 Nov 83 08:47:55 GMT (Tuesday)
From: Schwartz.rx
Subject: Re: NEW PLACE: Introductory Talk on Interscript Standard
In-reply-to: Your message of 8 Nov 83 08:45:33 GMT (Tuesday)
To: talbot
cc: Schwartz, Mitchell.PA, Ayers.PA 

John,

Sorry, I should have copied you when I requested a videotape.

Jim and Bob,

John Talbot and I are both in Welwyn Hall, so only 1 copy is necessary for the two requests. 

Thanx, Victor

----------
Date:  1 Nov 83 05:52:46 GMT (Tuesday)
From: Schwartz.RX
Subject: Re: Introductory Talk on Interscript Standard
In-reply-to: Ayers.PA's message of 31 Oct 83 16:38:04 PST (Monday)
To: Mitchell.PA, Ayers.PA
cc: Schwartz

Gents,

Could you please arrange to send a copy of the videotape to those of us in SDD/Welwyn Hall?

Cheers!

Victor
*start*
00680 00100 US 
gvMsgID: Spencer.PA $ 20#159@ 8-Nov-83  7:52:57 PST
Categories: InterScript
Date: Tue, 8 Nov 83 07:53 PST
From: Spencer.PA
Subject: interscript
To: Mitchell
cc: Schroeder, Allen, Spencer, Elkind

Jim, in rereading the Glavin note, I find that he is interested only the status of Interscript.  Would you be kind enough to put together a page tthat would be suitable for that high level that gives current status, completion plans, and any other info that ;you feel is relevant?  You might also give a bit of the parc philosophy on the licensing or release or what ever regarding standards and systems.  Bill will be here on Thur evening and Fri Morning.  

*start*
00651 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 8-Nov-83  9:53:59 PST
Categories: InterScript
Date:  8 Nov 83  9:54:08 PST
From: mitchell.pa
Subject: Re: interscript
In-reply-to: "Spencer's message of Tue, 8 Nov 83 07:53 PST"
To: Spencer
Cc: Mitchell, Schroeder, Allen, Elkind

Bill,

Okay, I will put together a one-page executive summary for Bill Glavin on the current state of Interscript, completion plans, and the current issues involved in releasing it (for some values of "releasing" and "it").  I will get it to you by Thursday.

--Jim Mitchell

�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ˜Jš�œ0˜;Jš�œ	˜Jš�œ$˜&J˜J˜“—…—
Î(*start*
01845 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 8-Nov-83 10:02:26 PST
Categories: InterScript
Date:  8 Nov 83 10:02:40 PST
From: mitchell.pa
Subject: Interscript summary for Glavin
To: Rowe, Ayers, Horning, Lampson
Cc: Mitchell

Folks,

I think the following request from Bill Glavin via Bill Spencer represents a real opportunity to clarify the "should we release Interscript?" debate.  I propose to write a one-page statement for Glavin, and I would appreciate your input and feedback on my drafts of it.

--Jim M.

--------------------------------------
Date: Tue, 8 Nov 83 07:53 PST
From: Spencer.PA
Subject: interscript
To: Mitchell
cc: Schroeder, Allen, Spencer, Elkind

Jim, in rereading the Glavin note, I find that he is interested only the status of Interscript.  Would you be kind enough to put together a page tthat would be suitable for that high level that gives current status, completion plans, and any other info that ;you feel is relevant?  You might also give a bit of the parc philosophy on the licensing or release or what ever regarding standards and systems.  Bill will be here on Thur evening and Fri Morning.  


--------------------------------------

Date:  8 Nov 83  9:54:08 PST
From: mitchell.pa
Subject: Re: interscript
In-reply-to: "Spencer's message of Tue, 8 Nov 83 07:53 PST"
To: Spencer
Cc: Mitchell, Schroeder, Allen, Elkind

Bill,

Okay, I will put together a one-page executive summary for Bill Glavin on the current state of Interscript, completion plans, and the current issues involved in releasing it (for some values of "releasing" and "it").  I will get it to you by Thursday.

--Jim Mitchell

--------------------------------------
�Êœ˜Jš
œ˜Jš
œ˜JšÐbsœ ˜'Jš�œ˜!Jš�œ
˜J˜J˜ŸJ˜š
œ&˜&J˜Ä—Jš
œ&˜&J˜Jš
œ˜Jš
œ˜Jš
œ˜Jš
œ;˜;Jš
œ˜Jš
œ&˜&J˜J˜“Jš
œ&˜&—…—0Ò*start*
00768 00096 US 
gvMsgID: rowe.PA $ 194#8@ 8-Nov-83 11:04:39 PST
Categories: InterScript
Date:  8 Nov 83 11:04:41 PST (Tuesday)
From: rowe.PA
Subject: Interscript
To: Elkind.pa
cc: Ayers.pa, Horning.pa, Mitchell.pa, Pierce.dlos, rowe

Jerry,

Last thursday a meeting was held with Bob Ayers, Jim Horning, Jim Mitchell, Roy Pierce and myself to review the aggravating problem of mediocre national and international standards for document interchange.

The time has come to inject sound principles into the ANSI/ISO committees.  We wish to use our meeting with you on November 11th to reinforce our recommendations contained in the meeting report being sent to you separately, and to initiate the publication clearance procedure for the proposed document.

Steve
*start*
00463 00100 US 
gvMsgID: Garlick.PA $ 60#105@ 8-Nov-83 15:46:36 PST
Categories: InterScript
Date:  8 Nov 83 15:46:48 PST (Tuesday)
From: Garlick.PA
Subject: Re: NEW PLACE: Introductory Talk on Interscript Standard
In-reply-to: Ayers' message of 7 Nov 83 15:49:42 PST (Monday)
To: Mitchell, Ayers
cc: Garlick

Please put me on the list to view the video tape of your talk. I envision becoming a client of interscript in the context of conversion services.
*start*
00471 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 8-Nov-83 18:05:08 PST
Categories: InterScript
Date:  8 Nov 83 18:04:30 PST (Tuesday)
From: Ayers.PA
Subject: Feedback on the Talk
To: Mitchell
cc: Ayers

1. I think it went pretty well.

2. I need to find a better stopping-place in discussing POUR$.

3. People didn't realize that BOX$ nodes are the ONLY nodes that affect layout.

4. I believe that TAG$ definition of tags needs either more or less said about it.

Bob
*start*
00367 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 8-Nov-83 19:28:08 PST
Categories: InterScript
Date:  8 Nov 83 19:27:31 PST (Tuesday)
From: Ayers.PA
Subject: Interscript Talk Slides
To: Mitchell

I propose that we each print a set of the actual slides used. We can then attach copies to the videotapes to make it easier for people to look at the talk on tape.

Bob
*start*
02659 00099 US 
gvMsgID: Linden.PA $ 194#38@ 9-Nov-83 10:53:53 PST
Categories: InterScript
Date:  9 Nov 83 10:48:23 PST (Wednesday)
From: Linden.PA
Subject: Boeing Presentation on Architecture and Interscript, Dec. 8
To: Ayers
cc: Mitchell, Linden, Elkind, Murphy

Bob, would you like to make this trip to Boeing?  This is visit where we talk to their architectural board and complete the process of undoing their edict that Xerox is not compatible with their long term direction.  It's also the beginning of a relationship where they do some document conversion products for us for release in 1985.
 
----------------------------------------------------------------

Date:  7 Nov 83 17:52:54 PST
From: mitchell.pa
Subject: Re: Interpress presentation at Boeing 12/8
In-reply-to: "Linden's message of 7 Nov 83 10:29:13 PST (Monday)"
To: Linden
Cc: Horning, Mitchell, Murphy, Elkind

I would be willing to go on this trip, but it seems to me that Bob Ayers would be a better candidate.  Has anyone asked him?

--Jim M.
----------------------------------------------------------------
Date:  7 Nov 83 10:29:13 PST (Monday)
From: Linden.PA
Subject: Interpress presentation at Boeing 12/8
To: Horning, Mitchell
cc: Linden, Murphy, Elkind

I believe this is a request for one of you to come up to Seattle for this new date.  Please talk to Jerry with questions. 

----------------------------------------------------------------
Date: Fri, 4 Nov 83 12:29 PST
From: Murphy.PA
Subject: Re: Boeing trip Nov 30 - Dec. 1
In-reply-to: "Linden's message of 31 Oct 83 11:31:09 PST (Monday)"
To: Linden
cc: Elkind, Horning, Garlick, Mitchell, Rabinovitch, Murphy

Ted,

As you suggested, I contacted Ken Larsen, the NAM for Boeing, and told him that Jerry had to be in Munich 11/29 and 11/30. He contacted Boeing and they decided on 12/8 and 12/9 for the meeting.  The network architecture portion of the meeting (coordinated by Flexer) is scheduled for half a day on the 8th, the rest of the meeting (?) is coordinated by Martin Ritchie and is scheduled for the 9th. 

I suggested someone set up a tentative agenda so we could see what was planned.  Ken said he would ask Flexer and Ritchie to write down their objectives and send them to us as soon as possible.

Jerry says yes, they do want an Interscript presentation.  I will remind him about your question on plans for them implementing products that use our protocols.

I hope to get more information on this next week, but wanted to let you know where it stands now.

Jan  


----------------------------------------------------------------

----------------------------------------------------------------
*start*
01031 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 9-Nov-83 11:38:32 PST
Categories: InterScript
Date:  9 Nov 83 11:38:25 PST
From: mitchell.pa
Subject: Re: Interscript Talk Slides
In-reply-to: "Your message of 8 Nov 83 19:27:31 PST (Tuesday)"
To: Ayers
Cc: Mitchell

Sending copies of our transparencies with video tapes of the talk sounds like a good idea.  I would like to suggest that you or someone in SDD put my slides into Star and combine them with yours in a consistent style.  I have put them on [indigo]<interscript>slides>interscript-nov83.slides.tioga

Ken Beckman is making three copies of the two video tapes of the talk yesterday so that we can send them to various places.  I "generously" told him that SDD would happily pay for the copies.  He will put a title on the tape as well.  By the way, the transparencies show up very well on tape (it's still a good idea for folks to have copies of their own, however).

--Jim
�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ˜$Jš�œ3˜>Jš�œ˜	Jš�œ
˜J˜J˜�—…—J¤*start*
02966 00096 US 
gvMsgID: Suk.PA $ 194#50@ 9-Nov-83 16:46:50 PST
Categories: InterScript
Sender: Suk.PA
Date:  9 Nov 83 16:47:09 PST (Wednesday)
Subject: "Introduction to Interpress" Document
To: OSBU^.es, DocStandards^.pa, DocumentInterchange^.pa, IPDesign^.pa, IPImpl^.pa, IPImplementors^.es, IPInterest^.pa, NetStandards^.wbst, NPA^.wbst, PrintingProtocolDesign^.es, PrintingProtocolImplementors^.es,  PrintingProtocolInterest^.es, PrintServiceInterest^.es, ServicesImplementors^.es, ServicesInterest^.es
To: L Bond ESDS A1-65<ESMail.es>,  P England ESCP P3-16<ESMail.es>,     A Lipton ESDS M1-16<ESMail.es>,     T Ogi ESDS A3-55<ESMail.es>, M A Henderson DLOS 199<ESMail.es>, C Jacobson DLOS 129/550<ESMail.es>, R Pierce DLOS 625A<ESMail.es>,      N Reed DLOS 185<ESMail.es>,    W Swanstrom DLOS 185<ESMail.es>, R Vance DLOS 134<ESMail.es>, L Van Gunten HADB FM227<ESMail.es>,      W White HADB F111<ESMail.es>, J Woolbright HADB FM227<ESMail.es>
To: R Boehner WBST 129<MCMail.wbst>,  C Holt WBST 129<MCMail.wbst>,   P Lavallee WBST 128<MCMail.wbst>,     D Wilkie TOHQ 6800<MCMail.wbst>
To: Blake.RX, Reid@Glacier, Sproull@CMU-CS-VLSI
To: K Oikawa<FXMail.fx>
To: R Stern<Kurzweil>
cc: ExtStds^.wbst, Drosdek.wbst, Library, Murphy, Warner
From: OSD Technical Publications <OSD-Pubs.pa>
Reply-To: OSD-Pubs.pa



This is to announce the availability of the (long-promised)

	Introduction to Interpress	June 1983	XSIG 038306


ABSTRACT:

"This publication provides an introduction to the Interpress standard and gives a number of examples.  The first chapter is a survey of the concepts and facilities of Interpress.  The remainder of the publication is directed to the system designer and programmer who are designing software to create Interpress masters.  This publication is intended to be read in conjunction with the reference document for the standard, *Interpress Electronic Printing Standard*, XSIS 048306."


TO OBTAIN YOUR COPY:

If you are a full-time permanent Xerox employee working in Northern California, you may request a copy of this document by replying to this message, giving your name and building number (and mailing address if outside the PARC mailroom service area), or by calling Suzi Winch at (415)494-5886.

If you are a full-time permanent Xerox employee working somewhere other than Northern California, order from Jerry <Mendelson.es>, 8*823-9520.

If you are a part-time or contract employee and need this document in your work, please have your Xerox supervisor make the request to the appropriate source.

Please remember that anything associated with Interpress is to be held strictly within Xerox.  Single copies are available to Xerox employees only.  It takes the personal approval of Bob Adams, together with a signed non-disclosure agreement, before any Interpress information may be disseminated outside of Xerox.

Copies are available in Palo Alto now, and should be available in El Segundo within two or three days.
*start*
03670 00100 US 
gvMsgID: mitchell.pa $ 3#171@ 9-Nov-83 18:20:27 PST
Categories: InterScript
Date:  9 Nov 83 18:20:34 PST
From: mitchell.pa
Subject: One page description of Interscript for Bill Glavin
To: Ayers, Lampson, vanLeunen
Cc: mitchell, Horning

Bill Glavin has asked for a one-page summary of Interscript covering current status, completion plans, and any other info that we feel is relevant for his visit to PARC on Friday.  We would appreciate your prompt feedback on this draft (we intend to give it to Spencer early tomorrow afternoon).

Thanks,

--Jims H. and M.


It is difficult to interchange documents among editing systems of varying capabilities while faithfully retaining their content, form, and structure.  Interscript is a standard that makes this possible and will enable Xerox to develop compatible products that range in power from a MemoryWriter or a personal computer to a high-performance workstation.
The development of Interscript began as a research project in PARC/CSL in May 1981 and has continued as a joint effort with OSD.  A first draft of the standard was released for comment to all interested Xerox organizations in September 1983.  A certain amount of work remains to be done to perfect the document describing the standard.  However, we believe the research issues for interchanging text documents have all been resolved and that we have a standard more advanced and expressive than any external proposal.
Several things need to be done by product organizations before Xerox realizes the potential of Interscript by introducing Interscript-conforming products:
The standard must be accepted by the SISB.
A schedule for the introduction of conforming products must be adopted.
Several prototype implementations on various processors must be developed.
A document explaining how to implement conforming editors must be written.
Technical staff in the product organizations must be trained in Interscript.
The factor currently limiting progress in these areas is a lack of people assigned to them by the relevant product organizations.  There are currently two people in the OSD publishing project (PICS) working on one prototype implementation, and one of them has also begun educating technical staff about Interscript.  We are not aware of anyone else for whom these tasks are a primary responsibility.  
There is one other matter that urgently requires a management decision: We are concerned by the rising tide of limiting document interchange standards in national and international organizations such as ANSI, ECMA, and ISO.  These bodies are well on the way to adopting standards that are not expressive enough for the rich interactive text and graphics features of Xerox products.  We believe that it is important to prevent premature standardization and to raise their aspiration levels by introducing Interscript for their consideration.
If we are to get Interscript concepts considered in the next ANSI/ISO four-year cycle, they must be introduced at the January 9th meeting of the relevant ANSI committee.  Roy Pierce, our representative on that committee, can arrange for Butler Lampson to give a presentation at that meeting.  A written document must be made available to the participants in early December.  We are preparing a slightly expurgated version of the Interscript standard for this purpose, and are requesting immediate clearance.  We recognize that early exposure of Interscript may be somewhat controversial, so we are drawing it to your attention now. 


�ʃ˜Jš
œ˜Jš
œ˜JšÐbsœ5˜<Jš�œ˜Jš�œ˜J˜ÂJ˜J˜Ibody˜àK˜…K˜š
K˜*K˜GK˜JK˜JK˜LIblock˜‘K˜œK˜øJ˜
—…—
j
ó*start*
00664 00099 US 
gvMsgID: vanLeunen.pa $ 3#7@ 9-Nov-83 21:10:37 PST
Categories: InterScript
Date:  9 Nov 83 21:10:44 PST
From: vanLeunen.pa
Subject: Re: One page description of Interscript for Bill Glavin
In-reply-to: "mitchell's message of 9 Nov 83 18:20:34 PST"
To: mitchell
Cc: vanLeunen

We would appreciate your prompt feedback on this draft (we intend to give it to Spencer early tomorrow afternoon).
It's mostly wonderful; let's sit down together first thing when you get in tomorrow morning and do a small little bit of touching up. 
�Êl˜JšÐbsœ˜Jš�œ˜Jš�œ9˜@Jš�œ/˜:Jš�œ
˜Jš�œÏt	˜
Iindentš
žs˜sIlead1˜†
—…—
Ä6*start*
00868 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Nov-83 11:12:40 PST
Categories: InterScript
Date: 10 Nov 83 11:12:51 PST (Thursday)
From: Ayers.PA
Subject: Re: Boeing Presentation on Architecture and Interscript, Dec. 8
In-reply-to: Linden's message of 9 Nov 83 10:48:23 PST (Wednesday)
To: Linden
cc: Ayers, Mitchell, Elkind, Murphy

Before I answer either "would you like to make this trip" or say who I think is more suitable, some questions:

    1. Is it just an Interscript presentation or an Interscript-and-
       Xerox-use-of-it presentation? E.g. do we discuss either when, 
       if ever, Star might use Interscript and discuss the PICS project?
       
    2. Has the Boeing gang signed complete non-disclosure agreements such
       that Xerox future plans can be divulged to them?
       
    3. What other presenttions are planned for the 8-9th?
*start*
00929 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Nov-83 11:18:28 PST
Categories: InterScript
Date: 10 Nov 83 11:18:39 PST (Thursday)
From: Ayers.PA
Subject: Re: One page description of Interscript for Bill Glavin
In-reply-to: mitchell's message of 9 Nov 83 18:20:34 PST
To: mitchell

"Several things need to be done by product organizations before Xerox realizes the potential of Interscript by introducing Interscript-conforming products:
The standard must be accepted by the SISB.
A schedule for the introduction of conforming products must be adopted.
Several prototype implementations on various processors must be developed.
A document explaining how to implement conforming editors must be written.
Technical staff in the product organizations must be trained in Interscript."

    You might say "not in this order" since we believe that the prototype 
    implementations should preceed formal acceptance by the SISB.
*start*
00429 00097 US 
gvMsgID: Ayers.PA $ 60#91@10-Nov-83 11:30:10 PST
Categories: InterScript
Date: 10 Nov 83 11:30:22 PST (Thursday)
From: Ayers.PA
Subject: Re: One page description of Interscript for Bill Glavin
In-reply-to: mitchell's message of 9 Nov 83 18:20:34 PST
To: mitchell

After the first sentence, how about a parenthetical note "(conversions necesarily lose information)" to stress the point about retaining ...
*start*
00522 00098 US 
gvMsgID: Elkind.PA $ 48#27@10-Nov-83 13:32:47 PST
Categories: InterScript
Date: Thu, 10 Nov 83 13:33 PST
From: Elkind.PA
Subject: Interscript Meeting
To: Rowe, Horning, Ayers, Mitchell
cc: Banks, Murphy, Elkind, Pierce.dlos

The Interscript meeting scheduled for 11 a.m. Friday, Nov. 11th, has been cancelled.  Would like to reschedule it to Wednesday, November 16th,  either at 9 a.m. or 1 p.m.  Please let me know as soon as possible which time you prefer.

Thanks,

Jan Murphy for Jerry Elkind 
*start*
00504 00100 US 
gvMsgID: mitchell.pa $ 3#171@10-Nov-83 14:25:17 PST
Categories: InterScript
Date: 10 Nov 83 14:25:10 PST
From: mitchell.pa
Subject: Re: Interscript Meeting
In-reply-to: "Elkind's message of Thu, 10 Nov 83 13:33 PST"
To: Elkind
Cc: Rowe, Horning, Ayers, Mitchell, Banks, Murphy, Pierce.dlos

I prefer 9:00 am on Wednesday because 1:00 conflicts with the CSL Dealer meeting.

--Jim Mitchell

�ÊS˜Jš
œ˜Jš
œ˜JšÐbsœ˜ Jš�œ0˜;Jš�œ˜
Jš�œ<˜>J˜J˜b—…—
<
•*start*
03881 00100 US 
gvMsgID: mitchell.pa $ 3#171@10-Nov-83 17:13:22 PST
Categories: InterScript
Date: 10 Nov 83 17:13:27 PST
From: mitchell.pa
Subject: MEMO - Bill Glavin re Interscript status
To: Mitchell


To    	Bill Glavin		Date	November 11, 1983
From	Jim Mitchell, Jim Horning,	Location	PARC
	Bob Ayers
Subject	Interscript status and plans	Organizations	CSL and OSD/SD
Interscript is a standard for the interchange of editable documents among a variety of editing systems, from simple word processors or personal computers to sophisticated workstations.  To interchange documents among products covering such a wide range of capabilities while faithfully preserving content, form, and structure is a difficult problem, but Interscript makes it possible.  It can give Xerox a major advantage in the integrated office-systems market.  
The development of Interscript began as a research project in PARC/CSL in May 1981 and has continued as a joint effort with OSD.  A first draft of the standard was released for comment to all interested Xerox organizations in September 1983.  Work remains to be done to perfect the standard.  But we believe that we have the potential for a standard more advanced and expressive than any other being proposed.
Several things need to be done before Xerox can capitalize on the potential of Interscript by introducing conforming products:
1. The full specification of the standard must be perfected.
2. A document introducing and explaining the standard must be written.
3. The standard must be accepted by the Xerox Systems Integration and Standards Board.
4. Several prototype implementations on various processors must be developed and a document explaining how to implement conforming editors written.
5. A schedule for the introduction of conforming products must be adopted.
6. Technical staff in the product organizations must be trained in Interscript.
Who is going to do these tasks?  We (Ayers, Horning, Mitchell) continue to work on the specification when our other responsibilities permit.  To the best of our knowledge, there is currently only one person in the OSD publishing project (PICS) working on a prototype implementation, and that person is Ayers; he has also begun educating technical staff about Interscript.  We are not aware of anyone else working on any of these tasks.
There is one other matter that urgently requires a management decision:  National and international organizations such as the American National Standards Institute (ANSI), the International Standards Organization (ISO), and the European Computer Manufacturers' Association are now considering document interchange standards.  These bodies are well on the way to adopting standards that will work to Xerox's disadvantage; these standards are not expressive enough for the rich interactive text and graphics features of Xerox products.  We believe that it is important to prevent premature standardization outside Xerox.  Interscript can raise the level of expectations, and raised expectations will work to Xerox's advantage.
If we are to get Interscript concepts considered in the next ANSI/ISO four-year cycle, they must be introduced at the January 9th meeting of the relevant ANSI committee.  Roy Pierce, our representative on that committee, can arrange for Butler Lampson to give a presentation at that meeting.  A written document must be made available to the committee members in early December.  We are preparing a version of the Interscript standard for this purpose, and are requesting immediate clearance.
We recognize that early exposure of Interscript may be somewhat controversial, so we are drawing this to your attention now. 


�ʾ˜Jš
œ˜Jš
œ˜JšÐbsœ*˜1Jš�œ
˜J˜J˜ImemoHeadšÏsœž
œ
žœ˜*Kšžœžœž
œ	˜8šžœž
œ˜AIbody˜ÐL˜™˜~Iindent˜<M˜FM˜VM˜“
M˜JM˜O—Iblock˜³L˜ÔL˜ìL˜}—J˜
—…—Æ*start*
00463 00099 US 
gvMsgID: Horning.pa $ 3#203@11-Nov-83 12:50:50 PST
Categories: InterScript
Date: 11 Nov 83 12:50:53 PST
From: Horning.pa
Subject: Re: Interscript Meeting
In-response-to: "Elkind's message of Thu, 10 Nov 83 13:33 PST"
To: Elkind
cc: Rowe, Horning, Ayers, Mitchell, Banks, Murphy, Pierce.dlos

I am tied up all day Wednesday, the 16th.

Jim H.

�ÊY˜JšÏsœ˜Jš�œ˜Jš�œ˜ Jš�œ.˜>Jš�œ˜
Jš�œ;˜>J˜J˜*J˜—…—

m*start*
01247 00099 US 
gvMsgID: Linden.pa $ 194#38@16-Nov-83 16:52:34 PST
Categories: InterScript
Date: 16 Nov 83 16:52:38 PST (Wednesday)
From: Linden.pa
Subject: Re: Boeing Presentation on Architecture and Interscript, Dec. 8
In-reply-to: Ayers' message of 10 Nov 83 11:12:51 PST (Thursday)
To: Ayers
cc: Linden, Mitchell, Elkind, Murphy

Bob, sorry I haven't gotten back to you sooner.

Re:    1. Is it just an Interscript presentation or an Interscript-and-
       Xerox-use-of-it presentation? E.g. do we discuss either when, 
       if ever, Star might use Interscript and discuss the PICS project?

I think it's both.

re:   2. Has the Boeing gang signed complete non-disclosure agreements such
       that Xerox future plans can be divulged to them?
Yes.

re:    3. What other presenttions are planned for the 8-9th?

Somebody up there is doing an agenda.  I'll talk about our plans for integration of Xerox and non-Xerox products and with external standards, Larry Garlick will talk about SNA interfaces.  There is a list of questions they are asking all vendors which they passed out at the last meeting, and we will have to respond to those, and then also while we are there, try to get some joint work on document conversion started.
*start*
01365 00097 US 
gvMsgID: Ayers.PA $ 60#91@23-Nov-83 15:42:48 PST
Categories: InterScript
Date: 23 Nov 83 15:44:49 PST (Wednesday)
From: Ayers.PA
Subject: Re: Boeing Presentation on Architecture and Interscript, Dec. 8
In-reply-to: Linden's message of 16 Nov 83 16:52:38 PST (Wednesday)
To: Linden
cc: Ayers, Mitchell, Elkind, Murphy
cc: Rowe

Ted, I briefly discussed the proposed Boeing presentation of 8 December with Steve Rowe, the PICS Project Manager.

I mentioned to Steve that I was somewhat nervous about discussing the PICS project with outside people, no matter what they've signed.

Steve agreed that this was a serious concern:

    If we just talk in general terms about Xerox strategy, it is
    meaningless: every vendor says thay are going to do wonderful
    things in the future.
    
    If we talk in concrete terms, describing an actual project, then 
    we are divulging important Xerox corporate strategy. Steve pointed
    out that a pattern is for RFQ answers to become RFQ queries on the 
    next go-around, and thus disseminate information to the industry.
    
Given my unerstanding of this meeting, and my and Steve's concerns, I feel that it is inappropriate for Xerox to discuss the PICS project with Boeing at this time.

That being the case, it is probably better for Jim Mitchell to discuss Interscript with them.

Bob 
*start*
01325 00099 US 
gvMsgID: Linden.pa $ 194#38@28-Nov-83 11:54:00 PST
Categories: InterScript
Date: 28 Nov 83 11:54:24 PST (Monday)
From: Linden.pa
Subject: Re: Boeing Presentation on Architecture and Interscript, Dec. 8
In-reply-to: Ayers' message of 23 Nov 83 15:44:49 PST (Wednesday)
To: Ayers, Mitchell
cc: Linden, Elkind, Murphy, Rowe, Garlick

Bob and Jim,  would you two get together and decide who goes.  Some clarification info follows.

This is an Interscript-and-Xerox-use-of-it presentation.  It is not necessary to discuss the PICS project.  (Although PICS is one future user of Interscript, details about it are not needed to describe future Xerox use of Interscript.)

Thur. Dec 8 is the architecture discussion starting after Jerry arrives from the 8:25 flight--i.e. starting at Boeing around 11:30.  I'll mail both of you the architecture questions they are asking.  Jerry wants interscript discussed in that presentation.

Fri. is Sunburst and possible joint development work on document conversion with Boeing.  They have been a beta test site for DCA.  We have a general proposal from them on this in the form of a letter.  Jan has a copy.  Bob, you might or might not want to stay for Fri. if you come, Jim presumably would not stay over.

I will have gone up on Wed. for a meeting with Microsoft. 
*start*
00536 00100 US 
gvMsgID: mitchell.pa $ 3#171@28-Nov-83 22:12:02 PST
Categories: InterScript
Date: 28 Nov 83 22:12:06 PST
From: mitchell.pa
Subject: Boeing Presentation on Architecture and Interscript, Dec. 8
To: Ayers
Cc: mitchell

Bob,

On Thursday, December 8 I am scheduled to meet with Steve Rowe and Bill Spencer about the PICS project.  It seems to me that I should do that rather than go to Boeing for the day? What do you think?

--Jim 

�ÊK˜Jš
œ˜Jš
œ˜JšÐbsœ=˜DJš�œ˜	Jš�œ
˜J˜J˜Õ
—…—
d
µ*start*
00597 00097 US 
gvMsgID: Ayers.PA $ 60#91@29-Nov-83 10:18:55 PST
Categories: InterScript
Date: 29 Nov 83 10:18:59 PST (Tuesday)
From: Ayers.PA
Subject: Boing 8 December
To: Mitchell

Sounds like you should stay here.

I jut talked with Linden on the phone, and it isn't at all clear that either one of us should be making the trip.

It supounds more like a smooth-ruffled-feathers show-the-flag trip than an exchange of technical views. And it appears that Interscript will be scheduled for around 45-60 minutes.

Anyway, we'll assume that its me-if-either-of-us that makes the trip.

Bob
*start*
00572 00099 US 
gvMsgID: Linden.pa $ 194#38@30-Nov-83 13:53:40 PST
Categories: InterScript
Date: 30 Nov 83 13:54:00 PST (Wednesday)
From: Linden.pa
Subject: Boeing visit
To: Ayers, 
cc: Mitchell, murphy, Linden.pa

I have given Ken Larsen a choice between a 2 hour very techincal talk on Interscript or a 15 minute overview.  He is checking with the Boeing people about what they want.  He was suggesting a 1 hour overview, but I said that isn't in the cards.  Bob, if they choose 2 hours, you get to go.  otherwise I can handle 15 minutes--maybe even 25 minutes!
*start*
00843 00106 US 
gvMsgID: Schwarcz.Siemens $ 194#64@ 1-Dec-83  7:08:09 PST
Categories: InterScript
Date:  1 Dec 83 07:08:16 PST (Thursday)
From: Schwarcz.Siemens
Subject: Re: Logistics of Meeting with Wolfgang Horak FRIDAY
In-reply-to: Ayers.PA's message of 30 Nov 83 17:49:28 PST (Wednesday)
To: Ayers.PA
cc: Schwarcz, Mitchell.PA

In the interest of achieving a meaninful dialogue I've not invited anybody else to join. Stephen Rowe would like to talk to Herr Horak sometime after he talks with you (two) and Jerry Elkind has said he would like to see him. I was going to join you so I wouldn't have to ask what happened, but several other meeting are going on at the same time and I don't think I'll be able to stay for the whole meeting. So... it looks like one of your offices will suffice. Let me know where to bring him.

Thomas
*start*
00971 00101 US 
gvMsgID: PIERCE.DLOS $ 19#130@ 6-Dec-83  9:29:19 PST
Categories: InterScript
From: PIERCE.DLOS
Date:  6-Dec-83 11:29:29 CST
Subject: INTERACTIVE INTERCHANGE 
To: DocStandards^.pa
cc: Pierce

Interactive interchange has been suggested within ISO/WG3 as one type
of text communication relevant to the current work of the SC18 organization.
It is not immediately apparent if interactive interchange will place
special requirements on Office Document Architecture (ODA) or the interchange
format (ODIF).  Working Group 3 would welcome comments as to the type of user
requirements that would need to be addressed for interactive interchange and
the possible impacts of those requirements on ODA and ODIF.

The Document Standards Committee members are requested to provide 
any comments pertinent to this subject.  A question that I believe is important
is the possible impact, if any, on Interscript.

(Document reference: ISO/TC97/SC18/WG3/N218)

Roy
*start*
00656 00098 US 
gvMsgID: Allen.PA $ 20#224@ 6-Dec-83 10:16:09 PST
Categories: InterScript
Date: Tue, 6 Dec 83 10:09 PST
From: Allen.PA
Subject: Meeting with Spencer-Steve Rowe, 8 December
To: Mitchell, Ritchie, Schroeder, PTurner
cc: Allen

I think I have discussed this meeting with all of you at various times.  Now I finally have time, place, etc. nailed down.  

The meeting to discuss Steve Rowe's electronic publishing project is now firmly scheduled for 12:00-2:00 p.m., Thursday, 8 December, in the Executive Conference Room.  Lunch will be served.  Please let me know if this presents any conflicts with your schedules.

Thanks, Dorene  

*start*
00891 00101 US 
gvMsgID: PIERCE.DLOS $ 19#130@ 6-Dec-83 11:38:42 PST
Categories: InterScript
From: PIERCE.DLOS
Date:  6-Dec-83 13:39:02 CST
Subject: Non Rectangular Layout Containers
To: DocStandards^.pa
cc: Pierce

A recent Canadian contribution to ISO (document interchange formats) proposed
the concept of non-rectangular blocks (layout containers).  I believe that
the purpose of the "angled" containers is to provide for kerning (I think 
that is the term used in the publishing community for the overlapping of characters into common character spacings).

As far as I know, the layout containers proposed in Interscript are only 
rectangular in shape.  Is this true?  Does our containerization technique
allow for kerning?

At the present time, ISO/WG3 layout techniques have been based on rectangular containers with the sides parallel to the image area,
i.e., the page.

Roy
*start*
00853 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 6-Dec-83 12:00:15 PST
Categories: InterScript
Date:  6 Dec 83 12:00:26 PST (Tuesday)
From: Ayers.PA
Subject: Re: Non Rectangular Layout Containers
In-reply-to: PIERCE.DLOS's message of 6-Dec-83 13:39:02 CST
To: PIERCE.DLOS
cc: DocStandards^

First, the Interscript draft does not detail how character-boxes are laid out. [We do not say how to put the "-" on the end of a hyphenated line, for example.]

But second, yes the Interscript draft could support kerning.

It would support it by allowing adjacent boxes to overlap. This facility is in the Interscript draft, together with a way to say that the overlap is "transparent".

An aside: I do believe that "angled" containers support genuine kerning. They would handle the general case of kerning italic, but won't handle various special cases.

Bob
*start*
00606 00100 US 
gvMsgID: mitchell.pa $ 3#211@ 6-Dec-83 14:13:53 PST
Categories: InterScript
Date:  6 Dec 83 14:13:46 PST
From: mitchell.pa
Subject: Re: Non Rectangular Layout Containers
In-reply-to: "Ayers' message of 6 Dec 83 12:00:26 PST (Tuesday)"
To: Ayers
Cc: PIERCE.DLOS, DocStandards^
Reply-to: mitchell.pa

I believe you meant to type "I do NOT believe that 'angled' containers support genuine kerning"
rather than "I do believe that 'angled' containers support genuine kerning".

--Jim Mitchell
�ÊW˜Jš
œ˜Jš
œ˜JšÐbsœ'˜.Jš�œ5˜@Jš�œ˜	Jš�œ˜J˜J˜J˜¼
—…—
ž
û*start*
00409 00100 US 
gvMsgID: mitchell.pa $ 3#211@ 6-Dec-83 15:53:07 PST
Categories: InterScript
Date:  6 Dec 83 15:50:48 PST
From: mitchell.pa
Subject: interscript slides press file
To: Ayers
Cc: mitchell

Bob,

My slides from the Interscript seminar are on [indigo]<Interscript>slides>interscript-nov83.slides.press

--Jim

�ÊJ˜Jš
œ˜Jš
œ˜JšÐbsœ˜&Jš�œ˜	Jš�œ
˜J˜J˜v—…—æ
6*start*
00466 00108 US 
gvMsgID: deLaBeaujardiere.pa $ 60#97@ 6-Dec-83 16:58:13 PST
Categories: InterScript
Date:  6 Dec 83 16:58:24 PST (Tuesday)
From: deLaBeaujardiere.pa
Subject: Re: Non Rectangular Layout Containers
In-reply-to: PIERCE.DLOS's message of 6-Dec-83 13:39:02 CST
To: PIERCE.DLOS
cc: DocStandards^
Reply-To: deLaBeaujardiere.pa

Are non-rectangular containers limited to horizontal trapezoids, or can they be polygons, ellipses, etc...?

	Jean-Marie
*start*
00569 00101 US 
gvMsgID: Bhushan.WBST $ 84#61@ 7-Dec-83 15:48:25 PST
Categories: InterScript
Date: 7 Dec. 1983 6:46 pm EST (Wednesday)
From: Bhushan.WBST
Subject: Interscript Overview Visuals
To: Mitchell.PA
cc: Bhushan

Jim,

I wonder if you have a set of visuals which provide an overview of Interscript. 
I remember you did one a year or two ago.  All presentation type material will be
greatly appreciated, as I have to occassionally give presentation to Management
on the standards.

Thank you

Abhay

Please mail information to: A. Bhushan, ROCH Wbst-129
*start*
00971 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 8-Dec-83 10:51:13 PST
Categories: InterScript
Date:  8 Dec 83 10:51:39 PST (Thursday)
From: Ayers.PA
Subject: Newer Version of Interscript "Concepts and Facilities"
To: Mitchell, Murphy(Elkind), ALBrown, Newlin, Wolf, Chang 
To: deLaBeaujardiere, Mallgren, Sandman, Gobbel, Porcar, Verplank
To: Asai, Wick, Smokey, Beard, Daniels, RHansen, Karlton, BLewis
To: Yee, Ladner, Wu, Merry, Plass, LKnutsen, DKnutsen, Kay, Roberts
cc: EPP-Interest^, Horning, Rowe
cc: Duncan

A brought-up-to-date (mostly) draft version of the Interscript "Concepts and Facilities" document is available as the folder

      Xerox:osbu north:McKinley>PubliC Ayers>InterS CandF Dec83
      
For those unable to retrieve or print Star documents from the 10MBit network, requesting the document from Duncan.pa will get you hardcopy via snail-mail.

Bob

PS: parse the "(mostly)" as modifying either "brought-up-to-date" or "draft" as you prefer. 
*start*
00689 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 8-Dec-83 17:01:03 PST
Categories: InterScript
Date:  8 Dec 83 17:02:41 PST (Thursday)
From: Ayers.PA
Subject: Aha! Our ECMA Representative Is ..
To: Rowe, ALBrown, Mitchell

----------------------------------------------------------------
Date:  8 Dec 83 13:33:49 GMT (Thursday)
Subject: I will be out of the office
To: OSMgrs^.es
cc: Englund, Talbot, DJones, SBD-E^, Luckman, Fishburn, Bowden, ATillotson
From: Anders Englund <Englund.rx>
Reply-To: englund.RX

I am attending an ECMA TC 24 meeting in Geneva Dec 9-16.
Back in the office on Dec 19.

David Jones (DJones.rx) will be in charge of INS Support during my absence.

	---Anders
*start*
00522 00100 US 
gvMsgID: mitchell.pa $ 3#211@ 8-Dec-83 18:26:42 PST
Categories: InterScript
Date:  8 Dec 83 18:26:32 PST
From: mitchell.pa
Subject: Re: Newer Version of Interscript "Concepts and Facilities"
In-reply-to: "Ayers' message of 8 Dec 83 10:51:39 PST (Thursday)"
To: Duncan
Cc: Mitchell

Please send me a hardcopy version of

Xerox:osbu north:McKinley>PubliC Ayers>InterS CandF Dec83

--Jim Mitchell (Building 35)
�ÊS˜Jš
œ˜Jš
œ˜JšÐbsœ<˜CJš�œ6˜AJš�œ˜
Jš�œ
˜J˜J˜}—…—
N
§*start*
00477 00100 US 
gvMsgID: mitchell.pa $ 3#211@13-Dec-83 11:30:57 PST
Categories: InterScript
Date: 13 Dec 83 11:30:50 PST
From: mitchell.pa
Subject: Roy Pierce's phone number has changed
To: Rowe
Cc: mitchell

Steve,

Roy Pierce's phone number has changed, and should be corrected on the Document Interchange Subcommittee list.  His new Intelnet number is 8*723-7329

--Jim Mitchell

�ÊP˜Jš
œ˜Jš
œ˜JšÐbsœ'˜.Jš�œ˜Jš�œ
˜J˜Jš
œ­
˜­
—…—
$
z*start*
02317 00095 US 
gvMsgID: LLi.es $ 44#67@14-Dec-83 13:06:18 PST
Categories: InterScript
Date: Wed, 14 Dec 83 13:06 PST
From: LLi.es
Subject: NEC PROPOSED NEW OA STANDARDS
To: StandardsReview^.pa, CharSetReview^.pa, CommunicationProtocols^.pa, CourierInterest^.pa, DocumentInterchange^.pa, ElectronicPublishingInterest^.pa
cc: 
Reply-To: LLi.es

My apologies if you have already seen this or if this is irrelevant to this distribution list.  However, I think that the following information may be interesting or useful to people involved or interested in developing Xerox standards.

---------------------------

Date: Wed, 14 Dec 83 12:41 EST
From: TIC.WBST
Subject: OA/FA UPDATE...A Monthly Report on Japanese Office and Factory Automation - Vol. I, No. 6 September, 1983
To: NewsLetters^.Wbst
Reply-To: TIC.WBST

NEC PROPOSED NEW OA STANDARDS
Nippon Electric Corporation (NEC) has announced that it will start developing and marketing various OA equipment whose designs are based on a new concept called "office information architecture (OIA)" -- a concept which basically concerns the systematic handling of office information. In particular, NEC has proposed two standards related to office automation (OA). One of them has to do with the concept of "information content architecture (ICA)," which essentially regulates the formats in which various types of information (e.g., Japanese, English, patterns, graphs, images, audio data, etc.) are expressed. The other standard concerns the concept of "information interchange architecture (IIA)," which regulates the modes of dissemination of information in information networks. Not only will the company develop and market the OA products of its own using these standards but it will also publicize the details of these standards through the "OA Convention," held this fall, with the hope of eventually promoting the standards to the status of international standards. The new standards proposed by NEC are basically protocols for OA machines, and IBM has already announced the development of similar protocols. However, NEC officials note that NEC's protocols have a wider scope, since they also deal with audio data and Japanese information, in addition to the standard English information.


------------------------------------------------------------

*start*
02308 00101 US 
gvMsgID: Pierce.dlos $ 19#130@16-Dec-83 15:40:03 PST
Categories: InterScript
From: Pierce.dlos
Date: 16-Dec-83 17:40:26 CST
Subject: Interscript Presentation at ANSI
To: Rowe.pa,Elkind.pa
cc: Mitchell.pa,Ayers.pa

Steve

Just to follow up on our phone conversation, I am writing down 
our agreements and action plans.  

I have scheduled Jim Mitchell to give a presentation on 
Interscript at the January meeting of ANSI X3V1, Office Systems.
The date of the presentation will probably be on either the 10th 
or 11th; I am confirming the exact date with the X3V1 Chairman.  
The presentation will probably take 1/2 day and will include a 
question and answer period.

My understanding is that Jim will present enough detail so that 
the X3V1 members will recognize that Interscript is more than a 
document architectural concept and either close to implementation 
or "lab testing."  

Some specific areas of Interscript may be witheld from the 
presentation based on "tactical" decisions by management.  This 
determination will be obtained by you and communicated to both 
Jim and myself.

I would appreciate your reply message concerning this topic.

I understand that the "famous" Goldfarb, the father of GML and 
strong supporter of SGML, will be presenting SGML at the January 
meeting.  Mr. Goldfarb is a member of X3J6, Computer Languages 
for the Processing of Text, and an employee of IBM.  His approach 
will be to show the value of SGML as the language for describing 
the logical structures/objects within an interchange format.  

From a tactical standpoint, I think that it would be good for Jim 
to present on the day following Goldfarb's presentation (if I can 
arrange it).  Goldfarb can present the concepts of logical 
structure and how SGML provides a means of interchange 
description,  then Jim can build upon this understanding and show 
the benefits of the Xerox approach.  A possible point for Jim's 
emphasis is that SGML was designed for manuscript authors 
(people) and Interscript was designed for document representation 
interchange.

Hope to hear from you shortly; sorry that I didn't get this 
message off before this.  I was suddenly called out of town to 
attend the Printing Standards Meeting.

Roy 

*start*
00598 00097 US 
gvMsgID: Ayers.PA $ 60#91@19-Dec-83 11:10:27 PST
Categories: InterScript
Date: 19 Dec 83 11:10:53 PST (Monday)
From: Ayers.PA
Subject: Re: Interscript Presentation at ANSI
In-reply-to: Pierce.dlos's message of 16-Dec-83 17:40:26 CST
To: Mitchell
cc: Rowe, Elkind, Pierce.dlos, Ayers

I understand, from my last conversation with Mitchell, that we need a "cleaned up" form of the Draft Standard.

[Note that there is now a draft "Concepts and Facilities" too.]

I am open to suggestions on what "cleaning it up" means.

I will be working on it beginning 28 December.

Bob 


*start*
00803 00101 US 
gvMsgID: pierce.dlos $ 19#130@19-Dec-83 13:19:23 PST
Categories: InterScript
From: pierce.dlos
Date: 19-Dec-83 15:19:34 CST
Subject: ANSI Presentation
To: Mitchell.pa
cc: Rowe.pa,Ayers.pa,Elkind.pa

Jim,
I talked with the X3V1 Chairman and his initial feeling isto have you
present just after Goldfarb on Monday the 9th.  This would put you on at
2:30 or 3pm and run until closing, say 5:30 or 6pm.  The problem
is that they have only scheduled the large meeting room for Monday when the
Plenary is in session.  During the week only small breakout rooms are avail- 
able  which would not be adequate for presenting to all of X3V1.  The chairman
is going to get back to me with a specific time by Wednesday.

It looks like Monday afternoon or Tuesday morning in either case.

Roy
*start*
17644 00099 US 
gvMsgID: Horning.pa $ 3#203@19-Dec-83 14:55:09 PST
Categories: InterScript
Date: 19 Dec 83 14:55:03 PST
From: Horning.pa
Subject: Document Interchange at Queen's University
To: Interscript
cc: Rowe, Elkind, Hall

Dave Barnard is a former student of mine, now running Computing Services at Queen's University (Kingston, Ontario, Canada). Several months ago he asked me for any information I could give him on this subject. Unfortunately, I had to tell him that, although we were actively working in the area, nothing had been cleared for public release.

The following illustrates a process that I'm sure is happening all over--go with what's available.

Jim H.

--------------------------------------
Received: from CSNET-CIC.ARPA by PARC-MAXC.ARPA; 19 DEC 83 01:21:47 PST
Date: 16 Dec 83 16:06:47 EST (Fri)
From: Barnard%QUCIS@CSNet-Relay.ARPA
Return-Path: <Barnard%QUCIS%QuCIS@CSNet-Relay>
Subject:  document transfer
To: horning.PA
Via:  QuCIS; 19 Dec 83 3:05-EST

Here is an internal document I have produced for local comment.  It was
unfortunately done on an IBM VM system, and then formatted before being
transferred to this (Unix) host to get access to CSnet, so please excuse
the multiple lines for emphasis technique.  I'd appreciate your comments.


  SCRIPT/VS R2.0: DEVICE 1403W6 CHARS MONO
 {
  
                       DRAFT - DRAFT - DRAFT
                       DRAFT - DRAFT - DRAFT
                       DRAFT - DRAFT - DRAFT
 :                     DRAFT - DRAFT - DRAFT
  
                Towards Integrated Document Handling
                Towards Integrated Document Handling
                Towards Integrated Document Handling
 :              Towards Integrated Document Handling
 :
    Background
    Background
    Background
 :  Background
  
 :  A great deal  of the work that faculty,  students, and staff
 :  at Queen's are  involved in entails the  production of docu-
 :  ments.  It should not be  surprising, then, that an increas-
 :  ing  amount of  computer usage  on campus  results from  the
 :  creation, modification, and distribution of documents, using
 :  word processing or document handling software.
  
 :  Some  of this  is done  on the  central academic  computers,
 :  using  the Script  program to  format  documents, and  other
 :  utilities (including PROFS) to distribute documents.  Output
 :  can be on dot matrix printers, typewriter-like devices, line
 :  printers, or the  6670 laser printer.  The  general approach
 :  is to  use an editor  to produce  a file containing  the raw
 :  text, together with  some markup tags.  These  tags are used
 :  by the formatting program to produce the copy for viewing on
 :  a screen or a printer.   Disadvantages of Script include the
 :  fact that editing  and formatting are done  by distinct pro-
 :  grams, and  the fact that  currently there is  no convenient
 :  way  for users  at Queen's  to produce  typeset output  from
 :  Script.
  
 :  Some document handling  is done using the  Q'Text program on
 :  PDP-11 microcomputers.  Output  can be on dot  matrix print-
 :  ers, typewriter-like devices, or an off-campus phototypeset-
 :  ter.  The general approach is to have editing and formatting
 :  combined in one program, and the  image on the user's screen
 :  is intended to be what will be produced on the printer (this
 :  is sometimes called "what you see  is what you get" or wysi-
 :  wyg).  Unfortunately,  the commands  input by  the user  are
 :  sometimes very low level and specific to a particular output
 :  device; further, since a normal display screen can only show
 :  characters of one font, the  facilities of a typesetter have
 :  to be invoked by embedding indicators  in the text, so that,
 :  at least for this application, what  you see is not what you
 :  get.  Disadvantages of Q'Text include  the low level of com-
 :  mands required, the fact that it  runs only on a limited set
 :  of machines, and  the fact that it  cannot communicate docu-
 :  ments to  any other systems so  that their structure  can be
 :  understood for further processing.
  
 :  In addition, there are other systems  in use.  Wordstar is a
 :  popular program in use on microcomputers, and there are oth-
 :  er  microcomputer-based programs  used  on  campus as  well.
 :  These generally follow  the Q'Text model, but  use different
 :  command sequences.  Departmental shared computing facilities
 :  (notably Computing and Information Science) can provide doc-
  
 :                                                             1
 {
  
 :  ument handling capabilities.  These generally follow the DCF
 :  model, but use different markup commands.
  
 :  The remainder of this document outlines an approach to inte-
 :  gration of document handling on campus.  Integration reduces
 :  costs, both to individuals and to  the University as a whole
 :  through its central support structures.  However, there will
 :  always be specialized needs.  There is no intent to prohibit
 :  some community  or individual  from using  other tools  than
 :  those described here; undoubtedly  specific cases will arise
 :  when other  approaches are  more desirable.   Users in  such
 :  circumstances must recognize that they  will have less "sup-
 :  port", both in terms of a smaller community of users to draw
 :  on, and a determinate reduction  in central resources.  This
 :  will be a "cost" incurred in other approaches, and should be
 :  taken into account.
  
    Desired Environment
    Desired Environment
    Desired Environment
 :  Desired Environment
  
 :  Terminals on the central system,  terminals on other systems
 :  around campus,  and individual  microcomputers will  be used
 :  for document creation.   It should be possible  to produce a
 :  document to be  used in the "Queen's  computing environment"
 :  at any  of these workstations.   Computing Services  will be
 :  responsible for providing software to allow supported micro-
 :  computers to  act as terminals to  the central host,  and to
 :  exchange files with the central host.  Thus, it would not be
 :  useful to  exploit the  peculiarities of  a wide  variety of
 :  document processing software  and produce a wide  variety of
 :  document architectures, which could then not be easily moved
 :  to another workstation or not understood there.
  
 :  This can be referred to as "input device independence".
  
 :  Screens  and low  quality  printers  in individual  offices,
 :  shared medium quality printers,  central high quality print-
 :  ers, and central  phototypesetting devices will be  used for
 :  document output.  A document in its  lifetime may be sent to
 :  several of these  devices.  It should be possible  to have a
 :  common document architecture that will allow this movement.
  
 :  This can be referred to as "output device independence".
  
 :  Both input and output device  independence are desirable for
 :  the overall environment  at Queen's, in order  to facilitate
 :  co-working, interchange of electronic documents, and rerout-
 :  ing  of documents,  and  to  allow replacement  of  existing
 :  equipment in  an orderly manner  when it is  appropriate and
 :  cost effective to do so.
  
 :  It is also highly desirable to  acquire software from a ven-
 :  dor who will enhance it to handle output devices that become
 :  available in  the future, and  to provide  increased sotware
 :  functionality.  In  particular, it does  not make  sense for
 :  Queen's to develop such software internally.
  
 :                                                             2
 {
  
    Possible Implementations
    Possible Implementations
    Possible Implementations
 :  Possible Implementations
  
 :  There are  at least three  ways of achieving  the uniformity
 :  described  here.   The term  Queen's  Document  Architecture
 :  (QDA) will be used to refer to a device independent document
 :  description.  This would  consist of a file  containing text
 :  plus markup commands (possibly DCF/GML).
  
 :  1) Any editor on  any system could be used to  produce a QDA
 :  document.  All documents would be sent to a central location
 :  for  formatting.  A  document could  then be  shipped to  an
 :  appropriate workstation or device  for viewing.  This allows
 :  no local  formatting, and is  unacceptable.  It  involves no
 :  development, but the function is too limited.
  
 :  2) Any editor on  any system could be used to  produce a QDA
 :  document.  A subset of the  formatting capabilities used for
 :  QDA would be provided in a program written by Computing Ser-
 :  vices.  This can be referred to  as Queen's Very Own Format-
 :  ter (QVOF).   This would  allow formatting  for screens  and
 :  printers on  microcomputers.  (Not  all formatting  features
 :  would be available.)   Documents would be shipped  to a cen-
 :  tral  location for  formatting and  output  on high  quality
 :  printers or phototypesetters.  This requires Computing Serv-
 :  ices to develop QVOF.
  
 :  3) A specified set of text processing programs could be used
 :  on the various systems  (including microcomputers) available
 :  on campus.  These programs could  have their own conventions
 :  for  document markup  and formatting.   Mappings from  these
 :  various architectures into QDA (and back?) would be defined,
 :  implemented and supported by Computing Services.
  
 :  In any of these approaches, it  is not strictly necessary to
 :  have QDA directly be input into  a program to drive a photo-
 :  typesetter.  If there was a Queen's Typesetting Architecture
 :  (QTA) different from  QDA, Computing Services would  have to
 :  provide a mapping from QDA to  QTA.  This would probably not
 :  be difficult.   Many users of  a typesetting  service (e.g.,
 :  journal editors,  authors of books)  would want  to (perhaps
 :  would have to) work directly in  QTA in order to gain access
 :  to  all  the function  of  the  typesetter.  Thus,  what  is
 :  expressible  in QDA  would  be a  subset  of  what would  be
 :  expressible in QTA.
  
 :  The third approach is preferable as it envisions total local
 :  document processing  where appropriate, yet gives  access to
 :  the shared  resources (quality  output devices,  and so  on)
 :  when that is desirable.  It must  be recognized that not all
 :  the function available in a local system will necessarily be
 :  automatically available by  moving the document to  a system
 :  using a  different document architecture.  High  level docu-
 :  ment markup cannot be inferred from a myriad of details in a
 :  document.
  
  
 :                                                             3
 {
  
 :  It should also be noted here  that use of microcomputers and
    communicating  word processors  is  to  be encouraged  where
                                                           where
                                                           where
 :                                                         where
    appropriate.  Standardization  is beneficial for  many users
    appropriate.
    appropriate.
 :  appropriate.
 :  and for many reasons, but does not entail centralization.
  
    A Model of Use of the System
    A Model of Use of the System
    A Model of Use of the System
 :  A Model of Use of the System
  
 :  The preferred environment can be viewed as a layered model.
  
 :  Level 1:  Many  end users and secretaries  working on micro-
 :  computers or  a mainframe.  Activities  are text  input, and
 :  proof formatting.   Output devices are Epson  quality print-
 :  ers, Diablo  quality printers,  or screens.   Some documents
 :  such as  letters and  memos might  not progress  beyond this
 :  level.  Ideally, this  would be a "what you see  is what you
 :  get" environment.   The hardware to  allow this  is becoming
 :  more financially  attractive, and  eventually will  be inte-
 :  grated with the software products currently used.
  
 :  Level 2:  Many end users and  secretaries working on a main-
 :  frame.  Activity is document formatting.  Output devices are
 :  all devices at Level 1, plus the 6670 laser printer (or oth-
 :  er shared  central high  quality printers).   Most documents
 :  will not progress beyond this level.
  
 :  Level 3:   Some end users  and secretaries, and  the Graphic
 :  Design Unit,  working on a  mainframe.  Activities  are page
 :  layout and  photocomposition.  Output devices are  hard copy
 :  all-points-addressable devices, or  raster graphics screens,
 :  showing final page layout but of limited quality.
  
 :  Level 4:   Very few  end users,  Graphic Design  Unit, Print
 :  Shop,  working on  a Queen's  mainframe,  or possibly  using
 :  off-site facilities.  Activity is formatting for a phototyp-
 :  esetter.  Output device is a phototypesetter.
  
    Current Status
    Current Status
    Current Status
 :  Current Status
  
 :  The current status is as follows.
  
 :  Level 1:  Software  is available on the  mainframe, and spe-
 :  cific products have been recommended for use on microcomput-
 :  ers.  Some  of the  micro software  can be  used to  develop
 :  documents that can be transferred to the mainframe and other
 :  micros.  Thus, DCF is becoming  the basis for QDA.  Communi-
 :  cations  and file  transfer software  is  available for  all
 :  recommended  micros.  Computing  Services  is continuing  to
 :  investigate methods  of mapping documents produced  by other
 :  recommended software  (Q'Text and Wordstar) into  the common
 :  format (QDA).
  
 :  Level 2:  Standard software on the mainframe can be used for
 :  high quality output.
  
 :  Level 3:  No current activity.
  
 :                                                             4
 {
  
 :  Level 4:  The  next release of the Script  processor for the
 :  VM system  (expected in  the first  quarter of  1984) should
 :  allow  Computing Services  to develop  software required  to
 :  drive an off-campus phototypesetter directly from a standard
 :  document.  (Negotiations have begun with  a printing firm to
 :  this end.)  No other activity.
  
 :  [Aside:  other document handling using products that are not
 :  integrated  into  this  overall approach  are  not  included
 :  here.]
  
 :  IBM has recently announced  the 4250 electro-erosion printer
 :  that produces high quality output  suitable for drafts prior
 :  to typesetting, and even for  final output for some typeset-
 :  ting applications.   This device is  driven by  standard IBM
 :  software.  (Any plan adopted by  Queen's must involve stand-
 :  ard software to ensure ongoing  support as software and out-
 :  put  devices  evolve;  the   complexity  of  these  programs
 :  precludes local development.)  The DCF system already in use
 :  drives the 4250 for text output.  Other products can be used
 :  for page layout and graphics.
  
    Recommendations
    Recommendations
    Recommendations
 :  Recommendations
  
 :  The following specific steps should be taken.
  
 :  I: Definition of a Queen's  Document Architecture by Comput-
 :  ing Services.  This will consist of a set of standard markup
 :  commands.
  
 :  II: Development  of software  by Computing  Services to  map
 :  documents from Q'Text  and Wordstar formats to  DCA, insofar
 :  as that is practical.
  
 :  III: Development of software by  Computing Services to drive
 :  a phototypesetter  from DCF  as soon  as possible.   Without
 :  capital exenditure this gives   Queen's a limited integrated
 :  environment.
  
 :  As a result of this experience further steps could be taken.
 :  These include acquisition of a  4250 and associated control-
 :  ler (initially  to be  located in  Computing Services  while
 :  software is  installed and  tested, eventually  to be  moved
 :  elsewhere), acquisition of the  additional software to drive
 :  the 4250, and acquisition of a graphics screen for page lay-
 :  out (to be located somewhere like Graphic Design, and avail-
 :  able by  booking for  staff and  faculty doing  complex jobs
 :  such as book layout).
  
    Conclusion
    Conclusion
    Conclusion
 :  Conclusion
  
 :  This strategic  direction provides an  integrated electronic
 :  document processing environment at  Queen's.  It provides an
 :  alternative approach  for users  requiring typesetting.   It
 :  thus  will eventually  broaden the  base  of user  expertise
  
 :                                                             5
 {
  
 :  available, and reduce the many  costs associated with a pro-
 :  liferation of special-purpose hardware and software for typ-
 :  esetting.  Q'Text and  Wordstar are options for  those users
 :  doing primarily local document preparation on a microcomput-
 :  er.
  
 :  It  should also  be attractive  financially.  A  significant
 :  amount of typesetting is done at Queen's already (calendars,
 :  Who's Where, Journal, etc.)  and  more will probably develop
 :  in the future.  All these  activities cost money:  some have
 :  dedicated hardware for specific pieces of software, and some
 :  of this is  expensive; all of it involves  production of the
 :  final pages  at organizations outside the  University (Who's
 :  Where at  about $12000 per year,  calendars at about  $5 per
 :  page).
 :
 :
 :
 :
 :
 :
 :
 :
 :
 :
 :
 :
 :
  
  
 :                                                             6
:: : _file transfer II             


--------------------------------------
�Êv˜JšÏsœ˜Jš�œ˜JšÑprsœ+˜3Jšžœ˜Jšžœ˜J˜Iblockš
œ¸˜¸K˜J˜š
œ&˜&J˜ó‚
—Jš
œ&˜&—…—DDŠ*start*
00913 00096 US 
gvMsgID: rowe.PA $ 194#8@20-Dec-83  9:14:47 PST
Categories: InterScript
Date: 20 Dec 83 09:14:53 PST (Tuesday)
From: rowe.PA
Subject: Re: Interscript Presentation at ANSI
To: Pierce.dlos
cc: Mitchell, Ayers, Elkind, rowe

Roy, thanks for your note of December 16.  I am glad that you and Jim Mitchell are progressing well towards the January ANSI meeting.

As we discussed, an edited version of the draft Interscript Standard is to be released to ANSI committee members. (Bob Ayers and Jim Mitchell have responsibility for creating the edited version).  In this regard there is general agreement that the encoding section (7) should be omitted.  Also, I would like Bob Ayers to take responsibility for removing those sections (if any) which put the PICS product development at risk.

I agree that Jim should speak after Goldfarb has done his SGML thing.

Good luck, Happy Christmas

Steve
*start*
00607 00100 US 
gvMsgID: mitchell.pa $ 3#211@20-Dec-83 15:50:49 PST
Categories: InterScript
Date: 20 Dec 83 15:50:38 PST
From: mitchell.pa
Subject: Re: ANSI Presentation
In-reply-to: "pierce.dlos's message of 19-Dec-83 15:19:34 CST"
To: pierce.dlos
Cc: Mitchell, Rowe, Ayers, Elkind, Sargent

Roy,

Okay, I will plan to fly to Austin on Sunday evening, January 8 and stay through Tuesday afternoon, January 10.  It sounds like that should cover it.  I will have my secretary make arrangements today.

--Jim

�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ˜Jš�œ3˜>Jš�œ
˜Jš�œ(˜*J˜J˜Ö
—…—
¢
ü*start*
00553 00098 US 
gvMsgID: Elkind.PA $ 48#27@21-Dec-83  9:03:45 PST
Categories: InterScript
Date: Wed, 21 Dec 83 09:04 PST
From: Elkind.PA
Subject: Re: Interscript Presentation at ANSI
In-reply-to: "Pierce.dlos's message of 16-Dec-83 17:40:26 CST"
To: Pierce.dlos
cc: Rowe, Elkind, Mitchell, Ayers

Roy,

I like the procedure you outlined.  What action if any do you expect X3V1 to take as a result of these presentations?  Is there any need to do a little lobbying with a few other companies to help get a positive response to our ideas?

Jerry

*start*
01805 00101 US 
gvMsgID: pierce.dlos $ 19#130@23-Dec-83  9:09:38 PST
Categories: InterScript
From: pierce.dlos
Date: 23-Dec-83 11:10:02 CST
Subject: ANSI Meeting
To: MITCHELL.pa
cc: Rowe.pa,Elkind.pa,Ayers.pa,Pierce

Jim,

The INTERSCRIPT presentation is scheduled for Monday afternoon just 
following the SGML presentation, by Goldfarb from IBM.  In order to get both
presentations before the total membership, the presentations have to be given
on Monday.  The SGML time was shortened and both presentors now have about 2 to 2 1/2 hours each.  I expect that SGML will run from 1 till 3 and Interscript will run from 3:15 until 5:30.

The meeting will be held in conference rooms at the Driscoll Hotel in Austin.
The phone number is 512-474-5911 if you wish to make your accomodations there.  The chairman has blocked off rooms for ANSI and you should
be able to get the reduced rate ($59-single) if you call and identify yourself.

SGML is going to be presented as a complete standard with encoding,syntax, and semantics "all ready to go."  This is 
going to be a strong selling point as ANSI is looking for something that 
they can present to ISO as a US contribution that is "more than conceptual."  Whatever you can do to represent INTERSCRIPT as a completed standard, within the 
limitations of disclosure set forth, will help considerably.  There are two
areas where we are weak strategically: 1) We are coming in somewhat belatedly in the project, 2) we are not disclosing certain parts that may be key
considerations in the minds of the majority of the membership.

You can contact me by electronic mail as I have a terminal at home,
or you can call me at 214-424-4179 (home) concerning anything on
our upcoming meeting.  Don't hesitate, I read the electronic mail almost
every day.

Roy
*start*
00541 00101 US 
gvMsgID: pierce.dlos $ 19#130@23-Dec-83  9:36:30 PST
Categories: InterScript
From: pierce.dlos
Date: 23-Dec-83 11:36:59 CST
Subject: Re: ANSI Presentation
In-reply-to: mitchell.pa's message of 20 Dec 83 15:50:38 PST
To: mitchell.pa
cc: pierce, Rowe.pa, Ayers.pa, Elkind.pa, Sargent.pa

Jim,

I will be driving to Austin on Sunday and hope to arrive in the early afternoon.  If you arrive early, I suggest that we meet for dinner and a little strategizing.  Give me a reply by email or leave a message at office.

Roy
*start*
00465 00100 US 
gvMsgID: mitchell.pa $ 3#211@30-Dec-83 16:11:50 PST
Categories: InterScript
Date: 30 Dec 83 16:11:43 PST
From: mitchell.pa
Subject: interscript document
To: Ayers
Cc: mitchell

Bob,

There is a press file with the current version of my stuff on [Indigo]<Interscript>DraftStd>Interscript-Standard.press

See you Monday at 3:30 pm.

Happy New Year.

--Jim

�ÊP˜Jš
œ˜Jš
œ˜JšÐbsœ˜Jš�œ˜	Jš�œ
˜J˜Jš
ϱ
˜±
—…—

n*start*
01231 00100 US 
gvMsgID: mitchell.pa $ 3#211@30-Dec-83 16:23:13 PST
Categories: InterScript
Date: 30 Dec 83 16:23:06 PST
From: mitchell.pa
Subject: Re: ANSI Meeting
In-reply-to: "pierce.dlos's message of 23-Dec-83 11:10:02 CST"
To: pierce.dlos
Cc: MITCHELL, Rowe, Elkind, Ayers

Roy,

I have made airline and hotel reservations for the ANSI meeting.  I will be arriving Sunday evening and leaving late on Tuesday afternoon.  I will send you details next week.

Bob Ayers and I will complete an "expurgated" version of the Interscript standard by Tuesday morning, Jan 3.  Rather than send it to you to distribute to the ANSI members, it seemed to me that we could distribute it directly from here (probably by some express service) and save time.  If you could stuff into a message the addresses of the people who are to receive a copy of it along with the text for a short cover letter, I will see that it gets sent out to them all.

Thanks,

--Jim Mitchell

P.S.  I will be away tomorrow and Sunday, but back on Monday.  My office number is 415/494-4456 and my home number is 415/494-1856 should you want to get in touch with me.

�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ˜Jš�œ3˜>Jš�œ
˜Jš�œ˜!J˜J˜Ô—…—l*start*
00337 00097 US 
gvMsgID: Ayers.PA $ 60#91@30-Dec-83 17:15:10 PST
Categories: InterScript
Date: 30 Dec 83 17:15:14 PST (Friday)
From: Ayers.PA
Subject: Re: interscript document
In-reply-to: Your message of 30 Dec 83 16:11:43 PST
To: mitchell

The "last edited" stamp says 27 October, but it looks like your new stuff is in it ...
*start*
00616 00096 US 
gvMsgID: rowe.PA $ 194#8@ 3-Jan-84  8:44:56 PST
Categories: InterScript
Date:  3 Jan 84 08:45:01 PST (Tuesday)
From: rowe.PA
Subject: ANSI Meeting
To: Mitchell, Ayers
cc: Rabinovitch, Shoch, Elkind, rowe

Sorry to give you such short notice but our company protocol requires that John Shoch and Jerry Elkind receive copies of material that we propose to disclose to the ANSI committee meeting later this month.  Would you please give John and Jerry this material as soon as possible so that they can react with any last minute recommendations that they might wish to make.

Thank you,

Steve
*start*
00910 00096 US 
gvMsgID: rowe.PA $ 194#8@ 3-Jan-84  9:07:09 PST
Categories: InterScript
Date:  3 Jan 84 09:07:14 PST (Tuesday)
From: rowe.PA
Subject: Document Interchange in Canada
To: Horning
cc: Elkind, Ayers, Mitchell, Rabinovitch, rowe

I found Dave Banard's note to be most interesting and am prompted to make the following responses:

1)	Is Banard (or a colleague) a possible author of the Implementors Guide to Interscript?

2)	Let's offer Banard and friends the same materials that we propose to offer ANSI in January: The objective would be to get their comments and support to adopt Interscript-like principles in their new standards activities.

3)	I also recommend that we begin a campaign of dissemination of Interscript concepts and priciples to selected U.S. and European universities and corporations.

By copy of this message I request Jerry's approval to process with 2) & 3).

Steve
*start*
00952 00097 US 
gvMsgID: Ayers.PA $ 60#91@ 3-Jan-84  9:19:54 PST
Categories: InterScript
Date:  3 Jan 84 09:20:43 PST (Tuesday)
From: Ayers.PA
Subject: Re: ANSI Meeting: documentation to Shoch and Elkind
In-reply-to: rowe's message of 3 Jan 84 08:45:01 PST (Tuesday)
To: rowe
cc: Mitchell, Ayers, Rabinovitch, Shoch, Elkind
cc: Pierce.dlos

It IS pretty short notice, Steve, since the current plan is to express the documentation to the ANSI committee members THIS AFTERNOON.

Jim and I will be happy to supply the documentation as you request, but to keep to Pierce's timeschedule we will have to say something like "objections not received in the next several hours cannot be considered."

Since the documentation is essentially the documentation that was supplied to Elkind last year, namely the Interscript Draft Standard minus chapter seven and with the semantics augmented by a little prose, a short-fuse "review" seems reasonable. 

Bob
*start*
00864 00099 US 
gvMsgID: Horning.pa $ 3#203@ 3-Jan-84 10:26:42 PST
Categories: InterScript
Date:  3 Jan 84 10:26:47 PST
From: Horning.pa
Subject: Re: Document Interchange in Canada
In-reply-to: "rowe's message of 3 Jan 84 09:07:14 PST (Tuesday)"
To: rowe
cc: Horning, Elkind, Ayers, Mitchell, Rabinovitch

Steve,

re 1). I imagine that Dave's staff would have been willing to work on the Implementors Guide had we been able to do 2) & 3) six months ago. It would probably be harder to get them to sign up now, but might be worth trying.

HOWEVER, I think they are more likely candidates to alpha-test the Implementors Guide than to write it. The latter will have to be done in very close collaboration with the Interscript developers.

Jim H.

�Êj˜JšÏsœ˜Jš�œ˜JšÑprsœ#˜+Jšž�
œ3˜@Jšžœ˜Jšžœ.˜1J˜Iblockš
œ­˜­K˜—…—Žþ*start*
01230 00100 US 
gvMsgID: mitchell.pa $ 3#211@ 3-Jan-84 10:33:40 PST
Categories: InterScript
Date:  3 Jan 84 10:33:25 PST
From: mitchell.pa
Subject: First crack at global values in Interscript (wrong)
To: mitchell
Cc: mitchell


6.2.  Global variables
To enable scripts to capture notions such as automatically assigned section or figure numbers, we need some kind of "global variables".  These can be built on the Interscript base language by defining to tags, GBIND and GVALUE, each of which has a relevant attribute, id, for the global variable to be assigned.  A GBIND$ node also has a second relevant attribute, the value, rhs, to be bound to the named global variable.  GBIND nodes should be allowable contents of any node and do not contribute any content to a node in which either might be embedded (in fact, they have no content of their own).
To bind a value v to the global variable gv, the script must contain a node of the form
{GBIND$ id_gv rhs_v}.  To access the value of gv, the script must contain an opened node of the form   


�Ê©˜Jš
œ˜Jš
Ïb˜JšÐbsœ5˜<Jšžœ
˜Jšžœ
˜J˜J˜
head˜Ibodyš
œÒ
ÐpsœŸœ*Ïeœ-Ÿœ8 œ-Ÿœ«
˜ØLšœ 
œ œ.Ÿœ œ
 œ
 œ
 
œ œ7˜¿
—J˜
—…—¼k*start*
00823 00098 US 
gvMsgID: Elkind.PA $ 48#27@ 3-Jan-84 14:18:57 PST
Categories: InterScript
Date: Tue, 3 Jan 84 14:21 PST
From: Elkind.PA
Subject: Re: ANSI Meeting: documentation to Shoch and Elkind
In-reply-to: "Ayers' message of 3 Jan 84 09:20:43 PST (Tuesday)"
To: Ayers
cc: rowe, Mitchell, Rabinovitch, Shoch, Elkind, Pierce.dlos

Bob,

Steve is correct.  Presentation of the Interscript document at the Ansi meeting is a publication just as presentation at ACM would be,  You need Shoch, Legal (Carouthers) and my approval.  I will be happy to expedite mine, but I can't speak for the other fellows (If someone gives me a paper clearance form I will sign it).  I suggest someone Get on the the phone especially to Carouthers and tell him what we're doing and also to John and make sure he's on board.  

Jerry 

*start*
02534 00101 US 
gvMsgID: PIERCE.DLOS $ 19#130@ 3-Jan-84 15:32:16 PST
Categories: InterScript
From: PIERCE.DLOS
Date:  3-Jan-84 17:33:03 CST
Subject: X3V1 Membership
To: Ayers.pa,Mitchell.pa
cc: Rowe.pa,Pierce

Bob,
 
Here are the names and addresses of the X3V1 membership.

John Azeltine
GTE Service Corp.
PO Box 1548-150
Tampa, Florida 33601

Mr. Steve Bankhead
OKI Systems Engineering
2200 east Spacecoast Parkway
Kissimmee, Florida 32741

Mr. R.H. Christie
Control Data Corporation
6003 Executive bLVD
Rockville, Maryland 20842

Mr. Denis Evangelista
Pitney Bowes
Walter H. Wheeler, Jr. Drive
Stamford, Connecticut 06904

Mr. Charles W. Forbes
AT&T, 59-2F28
99 Jefferson Road
Parsippany, New Jersy 07054

Mr. S.M. Garland
Teletype Corporation
5555 West Touhy Avenue
Skokie, Illinois 60077

Mr. S. Graham
Systems Engineering Lab, Inc.
6901 West Sunrise Boulevard
Fort Lauderdale, Florida 33313

Ms. Mary Jane Huneycutt
Hadron, Inc.
1951 Kidwell Drive
Vienna, Virginia 20904

Ms. Joan Knoerdel
National Bureau of Standards
Building 225, Room 226
Washington, D.C. 20234

Dr. James Mason
Text Management Specialist
Oak Ridge National Laboratory
PO Box X
Oak Ridge, Tennessee 37830

Mr. Herb Meister
Tandem Computer
2116 Kramer Lane
Austin, Texas 78758

Mr. Joseph McGovern
Sperry Computer System
P.O. Box 500-M.S.C.2-N.E.5
Blue Bell, Pennsylvania 19424

Mr. A. Miller
Automated Sciences Group
700 Roeder Road
Silver Spring, Maryland 20910

Mr. Mohan Moghe
Burroughs Corporation
Commerce Park
Danburry, Connecticut 06801

Mr. K.D. O'Niell
Time Computer
500 Old Connecticut Path
Birmingham, Mass. 01701

Mr. T. Pease
Booz, Allen & Hamilton
4330 East-West Highway
Bathesday, Maryland 20814

Roy Pierce

Mr. Joseph Resnick
U.S. Post Office Service
RND Labs-Unit 7
11711 Park Lawn drive
Rockville, Maryland 20852

Mr. D.M. Rosenberg
Honeywell Information Systems, Inc.
300 Concord Road
Billerica, Massachusetts 01821

Mr. Larry Tate
IBM Corporation
Department D 34/803
11400 Burnet Road
Austin, Texas 78758

Mr. R. Travis
Digital Equipment Corporation
ZK02-2/R94
110 Split Brook Road
Nashua, New Hampshire 03061

Mr. Gary Trenchard
GM Information Systems
EAS Staff
GM Text Center
Warren, Michigan
48090

Mr.William Tunnicliffe
Vice President, Information Technologies
Graphic Communications Association
1730 North Lynn Street
Arlington, Virginia 22209



I am composing a cover letter (or at least information to be put in a cover
letter) to be included with the Interscript documentation.  This should follow
within minutes.

Roy
*start*
01726 00101 US 
gvMsgID: pierce.dlos $ 19#130@ 3-Jan-84 16:13:28 PST
Categories: InterScript
From: pierce.dlos
Date:  3-Jan-84 18:13:31 CST
Subject: Cover Letter
To: Ayers.pa,Mitchell.pa
cc: Rowe.pa,Pierce

Bob-Jim,

I have sent a cover letter for mailing with the Xerox Interscript Contribution.
I don't have any strong feelings for the format or even whose name it is sent under.  The only key items are:
	-  Sent at my request, or from me---however you like.  Contributions
	   coming in are better received if the membership recognizes a name.
	-  Listed as Xerox contribution

Roy

----------------------------------------------------------------------------To:  X3V1 Membership

From:  Roy Pierce
       Chairman X3V1.3 Text Structures
       1341 West Mockingbird Lane
       Dallas, Texas 75247
       214-688-7329


Subject:  Xerox Contribution 

          "A Document Interchange Format"


The attached document, titled ?????????, is a Xerox contribution 
that will be presented at the January X3V1 ANSI Meeting in 
Austin, Texas.  

Mr. Jim Mitchell will be giving the presentation on Monday, the 
9th during the afternoon session.  Mr. Mitchell is (however you 
want to state it) and is employed at the (-----------) in Palo 
Alto, California.

(At this point I think we should state that the contribution 
represents several man-years of research work and is in some 
state of completion.  A brief promoting paragraph is in order)

This document is forwarded to you for your review prior to the 
meeting.  I apologize for the brief review period, however this 
contribution was just completed in the last few days.

I am looking forward to seeing you at the meeting.

RP 
*start*
02769 00100 US 
gvMsgID: mitchell.pa $ 3#211@ 4-Jan-84 11:09:02 PST
Categories: InterScript
Date:  4 Jan 84 11:08:45 PST
From: mitchell.pa
Subject: Cover letter for ANSI contribution
To: Ayers, pierce.dlos
Cc: mitchell

Here is my completed version of Roy's draft letter.  If you think it needs to be changed answer this message ASAP.

To:  X3V1 Membership

From:  Roy Pierce
       Chairman X3V1.3 Text Structures
       1341 West Mockingbird Lane
       Dallas, Texas 75247
       214-688-7329


Subject:  Xerox Contribution 

          Interscript, A Proposal for a Standard for the Interchange of Editable Documents


The attached document, Interscript, A Proposal for a Standard for the Interchange of Editable Documents, is a Xerox contribution that will be presented at the January X3V1 ANSI Meeting in 
Austin, Texas.  

Dr. Jim Mitchell will be giving the presentation on Monday, 9 January, during the afternoon session.  Dr. Mitchell is a Xerox Research Fellow working at the Palo Alto Research Center in California.

This work was begun two and a half years ago and has been a joint project of the Palo Alto Research Center and the Xerox Office Systems Division.  The research has focused on developing a representation for editable documents that is useful for a wide variety of editing systems, including simple word-processing editors, formatting and markup languages, interactive what-you-see-is-what-you-get editing systems, and sophisticated composition and publishing systems.  Because editing systems span a wide range of capabilities, Interscript has been developed to enable an editor to handle easily documents with parts that it does not "understand" (for example, to enable a text-only editor to handle a document with graphics in it without losing or compromising the integrity of the graphical parts).

This interchange format is really an interchange language.  The language is simple and compact, has a precise, formal semantics, and provides a powerful mechanism for definitional extension that enables standard constructs to be added readily to an existing standard.  The definitional mechanism also provides a formal language for describing all the constructs that make up the standard.

This current version of Interscript also includes a comprehensive layout model and various standard constructs (e.g., Paragraph, Text, Tables, etc.), all expressed as extensions to the base language.

This document is forwarded to you for your review prior to the meeting.  I apologize for the brief review period, however this contribution was just completed in the last few days.

I am looking forward to seeing you at the meeting.

RP 

�Ê`˜Jš
œ˜Jš
Ït˜JšÐbsœ$˜+Jšžœ˜Jšžœ
˜J˜Jšœ¿ÏePœŸPœ�	Ÿœ„˜†—…—

n*start*
02789 00100 US 
gvMsgID: mitchell.pa $ 3#211@ 4-Jan-84 11:39:45 PST
Categories: InterScript
Date:  4 Jan 84 11:39:43 PST
From: mitchell.pa
Subject: cover letter for ANSI
To: mitchell
Cc: mitchell


	Xerox Corporation
	1341 West Mockingbird Lane
	Dallas, Texas 75247
	214 688-7329
XEROX				January 4, 1984

To:	X3V1 Membership
From:	Roy Pierce
	Chairman X3V1.3 Text Structures
Subject:	Xerox Contribution
	Interscript, A Proposal for a Standard for the Interchange of Editable Documents
The attached document, Interscript, A Proposal for a Standard for the Interchange of Editable Documents, is a Xerox contribution that will be presented at the January X3V1 ANSI Meeting in 
Austin, Texas.
Dr. Jim Mitchell will be giving the presentation on Monday, 9 January, during the afternoon session.  Dr. Mitchell is a Xerox Research Fellow working at the Palo Alto Research Center in California.
This work was begun two and a half years ago and has been a joint project of the Palo Alto Research Center and the Xerox Office Systems Division.  The research has focused on developing a representation for editable documents that is useful for a wide variety of editing systems, including simple word-processing editors, formatting and markup languages, interactive what-you-see-is-what-you-get editing systems, and sophisticated composition and publishing systems.  Because editing systems span a wide range of capabilities, Interscript has been developed to enable an editor to handle easily documents with parts that it does not "understand" (for example, to enable a text-only editor to handle a document with graphics in it without losing or compromising the integrity of the graphical parts).
This interchange format is really an interchange language.  The language is simple and compact, has a precise, formal semantics, and provides a powerful mechanism for definitional extension that enables standard constructs to be added readily to an existing standard.  The definitional mechanism also provides a formal language for describing all the constructs that make up the standard.
This current version of Interscript also includes a comprehensive layout model and various standard constructs (e.g., Paragraph, Text, Tables, etc.), all expressed as extensions to the base language.
This document is forwarded to you for your review prior to the meeting.  I apologize for the brief review period, however this contribution has just become available in the last few days.  I am looking forward to seeing you at the meeting.


					Sincerely,


					Roy Pierce


�ÊܘJš
œ˜Jš
œ˜JšÐbsœ˜Jš�œ
˜Jš�œ
˜J˜J˜Iletterhead2š
ÐosQ˜QIblockšÏqœ˜LšÏbœ˜Lš œ-˜1Lš œÏeP˜mIlead1šœ¡Pœd˜Ë
Mš
ρ
˜Å
Mš
œŸ˜ŸMšœ1¡œË˜„Mš
ς
˜Ç
Mš
ϕ
˜ï
Lš
Ït#˜#J˜
—…—	 
‚*start*
00505 00099 US 
gvMsgID: Horning.pa $ 3#203@ 9-Jan-84 14:22:59 PST
Categories: InterScript
Date:  9 Jan 84 14:22:44 PST
From: Horning.pa
Subject: Interscript editing
To: Mitchell, Ayers
cc: Horning

I have persuaded Mary-Claire to take a look at the Introduction and Glossary, with the thought that the Blue&White might as well be as readable as we can make it without extreme exertion.

Jim H.
�Ê_˜JšÏsœ˜Jš�œ˜JšÑprsœ˜Jšžœ˜Jšžœ˜J˜Iblockš
œ¼
˜¼
K˜—…—
2
—*start*
00847 00100 US 
gvMsgID: Gittins.RX $ 100#32@17-Jan-84  2:13:11 PST
Categories: InterScript
Date: 16 Jan 84 22:30:00 GMT (Monday)
From: Gittins.RX
Subject: ECMA TC29 representation
To: Wheeler.wbst, Pierce.dlos
cc: Ayers.pa, Mitchell.pa, Elkind.pa, JWhite.pa, Cooper.RX, Gittins

Jack/Roy,

This is to let you know that following my departure from Rank Xerox membership of ECMA TC29 has been transferred to Martin Cooper. (Cooper.RX).  At the ECMA meeting last week I attended for the first two days and Martin stayed for the complete week, Martin will be sending a message outlining the results of the meeting.

One outcome of this is that it has been suggested that Martin should attend the ISO SG18 WG3 meeting in Geneva during February.  It is possible to arrange this, I am very uncertain of how representation on ISO works.

	Martin
*start*
02419 00096 US 
gvMsgID: BLAKE.RX $ 12#7@17-Jan-84  8:59:36 PST
Categories: InterScript
From: BLAKE.RX
Date: 17-Jan-84 11:57:35 EST
Subject: News release
To: AllHenr^.Henr, AllWbst^.Wbst, AllPA^.PA, AllES^.ES, AllDLOS^.Dlos, AllLB^.LB, AllRX^.RX, AllSTHQ^.STHQ
cc: Blake

This information has been transmitted at the request of the British National Computing Centre.

QUOTE
Subject: Recommendations from a study of Electronic Mailbox Systems.

"The British National Computing Centre (NCC) recently completed a study of Electronic Mailbox Systems. The study's recommendations are now being published to as wide an audience as possible in the belief that the issues raised are of crucial importance to the development and use of this communications medium.

The recommendations suggest that organisations need to implement mailbox systems to remain competitive; advise that a mailbox structures research program be initiated; proposes demonstrator projects to test ECMA, CCITT and ISO mailbox-related standards; encourages suppliers to provide a structuring capability in their products; and calls for the development of a programming language designed specifically for mailbox applications. You can see the full text of these recommendtions by messaging me if interested.

This message has been distributed simultaneously today, the 17th January 1984, to a total of over 62700 users inthe following mailbox systems:-
PRESTEL MAILBOX: GEISCOS QUIK-COM SYSTEM: BRITISH TELECOM NE INTERNAL SYSTEMS: USENET: HPS INTERNAL HPDESKMANAGER NETWORK: TEXAS INSTRUMENTS INC MSG NETWORK: ICL INTERNAL SYSTEMS: KOMEX FROM GMD (WEST GERMANY): COM: MAILNET: BLEND: XEROX INTERNET: STSC APL PLUS SIG ICEBOX: CSC NOTICE: JANET: ARPANET: NPL SCRAPBOOK AND EDIT SYSTEMS: EIES AT NJIT: NCCS ZYNAR NETWORK: COMET: DIGITAL INTERNAL (ALL-IN-ONE): ZYNAR/NESTAR NETWORK: IP SHARP ASSOCIATES MAILBOX: DATAPOINT ELECTRONIC MAIL SERVICE: INTERNAL PLESSEY SYSTEM: BELL NORTHERN RESEARCH COCOS.UNQUOTE"

We have distributed this without comment for the NCC and do not necessarily subscribe to the details of wording nor to the substance of all the recommendations. It is a demonstration of the capability of such systems to reach a wide audience and an encouragement towards standards in this whole field. Xerox has worked hard on the CCITT Message Handling recommendations to which this text refers.

NEIL BLAKE Rank Xerox London at BLAKE.RX
*start*
08250 00101 US 
gvMsgID: vanLeunen.pa $ 3#235@17-Jan-84 14:46:28 PST
Categories: InterScript
Date: 17 Jan 84 14:46:31 PST
From: vanLeunen.pa
Subject: Interscript Standard
To: Horning, Mitchell
Cc: vanLeunen

Jim Horning says I pass the Turing test:

Purpose and Overview:
Interscript defines a digital representation of editable documents for interchange among different editors.  A script is the representation of a document in Interscript format; it can be transmitted from one editor to another or stored for later editing.  A script is not limited to any particular editor; an editor that understands only some parts of a script and not others can edit the parts it understands without losing or altering the parts it does not understand.
Because this report is intended as a nascent standard, we have employed various formal notations for precision.  We have also included commentary in a number of places in fine print.  But the fine print should be viewed as hints about the standard; in any conflict, the normal-sized text is to be considered the correct version.
The casual reader may find the Introduction and Glossary helpful.
1. Introduction
Interscript provides a means of representing editable documents.  This representation is independent of any particular editor and can therefore be used to interchange documents among editors.
1.1 Rationale for an interchange standard
As editors proliferate, being able to interchange documents among them is becoming more and more important.  Customers need document compatibility to avoid being trapped in evolutionary cul-de-sacs without paying the awful price of converting documents from one system to another.
To provide good performance, a typical editor uses a highly encoded representation of a document.  Different editors use different, incompatible representations, and a user can conveniently edit a document only with the editor used to create it.  A program can convert a document from one representation to another.  But N editors will require N(N-1) programs to do direct conversion from each representation to every other representation.
We can reduce the number of conversion programs needed from N(N-1) to 2N by inventing a super-representation.  Now instead of converting directly from editor 1 to editor 2 we convert from editor 1 to the super-representation and from the super-representation to editor 2.  Using two programs is a minor drawback compared to writing N(N-1) programs.
Defining the super-representation correctly is crucial.  To convert documents faithfully from every editor to every other editor, the super-representation must incorporate all of the structures, formats, and content types used by all the real editors.  Furthermore, the super-representation places an upper bound on all future compatible editors; it must therefore accommodate features yet unknown.  The Interscript standard is an attempt to define such a super-representation.
Interscript has been developed by examining what information editors need and how that information can be organized.  It provides an external representation that is capable of conveying the content, form, and structure of editable documents.  The representation has only one purpose: to enable the faithful and efficient interchange of documents among different editors.  We call the Interscript representation of a document a script.
1.2 Properties than an interchange representation must have
An interchange representation for editable documents must satisfy a number of constraints:
Fidelity
Fidelity is the sine qua non for an interchange representation:  Converting a document from an editor's private representation to a script and back again must have no observable effect on the document's content, form, or structure.  It follows that, if anyone is to trust the fidelity of a standard, it must be possible to test whether two scripts are equivalent.
Universality
A script must not be tied to any particular hardware or any particular file format; scripts will be stored and transmitted using a variety of media.
Expressiveness
A script must be capable of describing virtually all editable documents, including those containing formatted text, synthetic graphics, scanned images, animated images, and mixtures of these various modes.
Scripts must record the association between content and form -- margins, leading between lines, fonts, etc.  Both the content and the form of typical documents require a rich value space containing scalar numbers, strings, vectors, and record-like constructs in order to describe items as varied as distances, text, coefficients of curves, graphical constraints, digital audio, scanned images, and transistors.
Many documents have hierarchical structure.  A book, for instance, is made up of chapters, the chapters are made up of sections, and the sections are made up of paragraphs; a page contains a frame, which contains a figure, which contains a caption and graphics; the description of an integrated circuit has levels corresponding to modular or repeated subcircuits.  A script should exploit such structure where it exists without imposing structure where it does not.
Scripts must capture characteristics acquired by indirection.  A set of paragraphs, for instance, may have a common form; changing the definition of the form will change all the paragraphs.  Or a document may be incorporated by reference in several other documents and inherit different characteristics in each.      
Accessibility
The program converting a script to an editor's private representation should be able to tell what parts of the script the editor can use and what parts it cannot.  For instance, even if the editor does not understand figures it might be able to handle the captions in the figures correctly.  And the editor's private representation must be able to preserve the information about the figures so that they can be passed back into a new script and regenerated by more sophisticated editors.  The syntax and semantics of scripts must therefore be simple enough so that they can be interpreted readily, even by very primitive editors. 
Efficiency
Since scripts will be stored, transmitted over networks, and converted, they should take up little space, and converting between a script and the private representations of the various editors should take little time.
Extensibility
The standard should not foreclose future options for documents that exploit additional media (such as audio) or require rich structures (such as VLSI circuit diagrams or database views).  The standard must be capable of incremental extension, and any extension must have the same guarantees and be able to employ the same mechanisms as the rest of the standard.
1.3 What the standard does not do
Interscript is not a file format.  The standard is not concerned with how scripts are held in files on various media (floppy disks, tapes, etc.) or with how they are transmitted over communications media (local area networks, telephone lines, etc.).
Interscript is not a standard for editing.  A script is not intended to be a directly editable representation.  It is not part of its function to make editing easier, more efficient, or more compact; that is the purview of editors and their associated private representations.  A script is intended to be converted before being edited; the conversion might be done by the editor, by a utility program on the editing workstation, or by a completely separate service.
Interscript does not directly help combine documents.  In general, it is no easier to glue two arbitrary documents together than it is to edit them.
Interscript does not overlap with other standards.  For instance, it does not address the issue of specifying encodings for characters in documents or the issue of how fonts should be named or described.
�Ê
š˜JšÐbsœ˜Jš�œ˜Jš�œ˜Jš�œ˜Jš�œ˜
Ilead1šÏt
œ(˜)Ilead2˜š
Ïl˜LšŸoÐilŸá˜ÖLš
ŸÈ˜ÈLš
ŸA˜A—š
Ÿ˜Lš
Ÿ¿
˜¿
š
Ÿ)˜)Lš
Ÿ˜˜˜Lš
Ÿ·˜·LšŸ«
Ðls
Ÿ°
˜ÜLš
ŸÝ˜ÝLšŸ« Ÿ
˜²—š
Ÿ;˜;Lš
ŸZ˜Zš
Ÿ˜LšŸ ŸÏ˜ë—š
Ÿ˜Lš
Ÿ”
˜”
—š
Ÿ˜Lš
ŸÍ
˜Í
Lš
Ÿš˜šLš
ŸÑ˜ÑLš
Ÿ½˜½—š
Ÿ
˜
Lš
Ÿö˜ö—š
Ÿ
˜
Lš
ŸÙ
˜Ù
—š
Ÿ
˜
Lš
Ÿé˜é——š
Ÿ!˜!Lš
Ÿù
˜ù
Lš
ŸÑ˜ÑLš
Ÿ”
˜”
Lš
ŸË
˜Ë
———…—6Ö*start*
00353 00099 US 
gvMsgID: Hutchins.PA $ 3#37@18-Jan-84 11:03:29 PST
Categories: InterScript
Date: Wed, 18 Jan 84 11:03 PST
From: Hutchins.PA
Subject: Publication Clearance
To: Mitchell
cc: Sargent, Hutchins

I have received the Publication Clearance on the Interscript-A proposal for a Standard for the Interchange of Editable Documents.

Diane

*start*
01589 00101 US 
gvMsgID: pierce.dlos $ 19#130@18-Jan-84 12:24:48 PST
Categories: InterScript
From: pierce.dlos
Date: 18-Jan-84 14:24:56 CST
Subject: Re: ANSI Interscript Presentation
In-reply-to: Your message of 14 Jan 84 15:34:10 PST (Saturday)
To: Rowe.pa,Mitchell.pa,Elkind.pa,Ayers.PA
cc: Pierce

Brief report on ANSI Meeting

Jim's presentation was well received.  Goldffarb's presentation was also well
received and the consensus of the members was that a document description
language, such as SGML or Interscript, is necessary for incorporation into the
ANSI Standard.

At this time, the SGML standard is viewed by the members of X3V1 as the best
candidate.  The reasons for this are:

	1.  sGML was there first (submitted over one year ago).
	2.  SGML vs Interscript comparisons did not show that either had
	    a distinct advantage over the other.  (Needs further work).
	3.  SGML is the output of another ANSI Committee and it would be 
	    better to have one standard than two.  

The strategy (my recommendation) at this point is:

	1.  Review SGML and Interscript comparisons.  (On its way to you).
	2.  Determine strengths/weaknesses of  each.
	3.  Based on #2, support SGML or continue to push for Interscript
	    adoption.

I am sending (by fax) a comparison of Interscript and SGML that was published at the X3V1 meeting.  I am requesting a quick review of that comparison so that we can make a decision about the upcoming ISO meeting.  If we feel that some
important Interscript advantages have been overlooked, we can emphasize them at
the ISO meeting.

Roy
*start*
01450 00101 US 
gvMsgID: pierce.dlos $ 19#130@18-Jan-84 13:00:59 PST
Categories: InterScript
From: pierce.dlos
Date: 18-Jan-84 15:01:02 CST
Subject: Re: ECMA TC29 representation
In-reply-to: Gittins.RX's message of 16 Jan 84 22:30:00 GMT (Monday)
To: Gittins.RX
cc: Wheeler.wbst, Pierce.dlos, Ayers.pa, Mitchell.pa, Elkind.pa, JWhite.pa, Cooper.RX

Martin/s

I just returned from the US ANSI Meeting at which SGML and Interscript were
presented as logical candidates for Office Document Interchange Format (ODIF).

The US approved SGML as the candidate due to its prior submission, 
similar capability, and support from ANSI's X3J6 Committee, "Computer
Languages for the PRocessing of Text."  Interscript was well received but did
not demonstrate any significant advantages over SGML.  

The comparison of SGML and Interscript is, I expect, an activity that Bob Ayers
and Jim Mitchell are evaluating in greater detail.  

The results of the evaluation will probably be the key ingredient for determining our next strategy.  I plan to attend the ISO meeting, as a US delegate 
supporting the US position, but also to further support Interscript, if thatappears appropriate.  Depending on our "forthcoming" strategy, I
would expect that your presence could be used to advantage.  Further thinking along these lines and dialogue is needed.  

I'll keep you posted from my perspective---please comment on what I've written so far.

Regards,

Roy
*start*
00894 00097 US 
gvMsgID: Ayers.PA $ 60#91@18-Jan-84 17:49:10 PST
Categories: InterScript
Date: 18 Jan 84 17:49:08 PST (Wednesday)
From: Ayers.PA
Subject: Re: ANSI Interscript Presentation
In-reply-to: pierce.dlos's message of 18-Jan-84 14:24:56 CST
To: Pierce.dlos
cc: Rowe.pa, Mitchell.pa, Elkind.pa, Ayers.PA

Roy, I don't undestand how SGML can be considered by X3V1 -- perhaps I don't understand the proposal.

As I understand it, SGML is that language that

  a. Has all the ".HEADER2" stuff in the manuscript
  
  b. Has a separate language which tells each specific printer instance
     how to print a "header2"
     
I also thought that X3V1 didn't get along with X3J6 -- what happened?

I will be happy to review stuff. I believe that I need the SGML gang's actual proposal, since (per the above) it has to be different than what I've thought of SGML in the past.

Bob
     

*start*
01851 00101 US 
gvMsgID: PIERCE.DLOS $ 19#130@19-Jan-84  8:13:15 PST
Categories: InterScript
From: PIERCE.DLOS
Date: 19-Jan-84 10:13:18 CST
Subject: Re: ANSI Interscript Presentation
In-reply-to: Ayers.PA's message of 18 Jan 84 17:49:08 PST (Wednesday)
To: Ayers.PA
cc: Pierce, Rowe.PA, Mitchell.PA, Elkind.PA

BOB,

The SGML of today is considerably advanced from the GML of yesterday.  It
still provides those features of GMLi.e., human markup using dot commands,
brackets and such, however it provides a document description metalanguage (refer to part 6 of the overall SGML Standard) that provides for constructs in a 
similar manner to that of Interscript.

My impression is that Bob was also a little surprised at what is offered by the current SGML.  I didn't get a chance to debrief with him 
as he had to leave right from the meeting and catch a plane.  I am 
interested in his analysis.

X3J6 and X3V1 were at odds, however the lack of a viable "document interchange 
covering both logical and layout has forced X3V1 to accept SGML as "the
only game in town."  As it turns out, SGML is not such a bad choice
(at least that is the current feeling of X3V1).

A current issue that faces X3V1 is that they are only proposing SGML to fill the "logical" side of the ODIF capability.  Everyone in X3V1 realizes that
this is not acceptable for the long run, but the strategy is to get SGML accepted for the logical portion and then show that SGML can do the layout portion also.  S.a, the CCITT technique for interchange of layout, will then be examinined and hopefully discarded.  X3V1 did not want to attack S.a directly since it has many supporters in the European (ISO) community.  An "oblique" attack
is x3V1's current approach.

I am trying to fax you the SGML/Interscript comparison so that you can better
evaluate the new SGML.

Roy
*start*
01223 00099 US 
gvMsgID: Horning.pa $ 3#203@20-Jan-84 10:00:53 PST
Categories: InterScript
Date: 20 Jan 84 10:00:56 PST
From: Horning.pa
Subject: Material for Canada?
To: Ayers, Rowe
cc: Interscript

Bob, Steve,

Do either of you want to take over this contact?

Jim H.

--------------------------------------
Received: from CSNET-CIC.ARPA by PARC-MAXC.ARPA; 20 JAN 84 00:37:21 PST
Date: 19 Jan 84 08:51:57 PST
From: barnard%qucis@CSNet-Relay.ARPA
Return-Path: <barnard%QuCIS@CSNet-Relay>
Subject: Interscript
To: horning.PA
Via:  QuCIS; 20 Jan 84 3:08-EST

Jim:
The whole area of text handling on campus and integration of existing and
expected facilities is receiving a great deal of discussion.  I had a 
meeting yesterday with all the Deans to explain what Computing Services is
thinking and intending.  We are being pressed to develop a standard, and in
the absence of anything more than we have already seen, will probably opt
for the wonderful world of IBM.  Is there any increase in the likelihood
of releasing Interscript material to us?
David

--------------------------------------
�Ês˜JšÏsœ˜Jš�œ˜JšÑprsœ˜Jšžœ˜Jšžœ˜J˜Iblockš
œ>˜>K˜J˜š
œ&˜&J˜ç—Jš
œ&˜&—…—ìe*start*
09038 00099 US 
gvMsgID: Horning.pa $ 3#203@20-Jan-84 15:31:49 PST
Categories: InterScript
Date: 20 Jan 84 15:30:57 PST
From: Horning.pa
Subject: Alternate Interscript Introduction
To: Keeper of the Flame <Ayers>
cc: Mitchell, Horning

Bob,

We would like to get the ANSI proposal between Blue&White covers. We hypothesize that there will be less hassle about clearance if we submit EXACTLY the document that has already been cleared (although even that is not guaranteed these days). We intend to discuss this with Ritchie, to see what he thinks.

Meanwhile, Mary-Claire has had a bash at the front matter; this seems to read better, and may be useful for the next internal version of the draft standard.

Jim H.

--------------------------------------
Date: 17 Jan 84 14:46:31 PST
From: vanLeunen.pa
Subject: Interscript Standard
To: Horning, Mitchell
Cc: vanLeunen

Jim Horning says I pass the Turing test:

Purpose and Overview:
Interscript defines a digital representation of editable documents for interchange among different editors.  A script is the representation of a document in Interscript format; it can be transmitted from one editor to another or stored for later editing.  A script is not limited to any particular editor; an editor that understands only some parts of a script and not others can edit the parts it understands without losing or altering the parts it does not understand.
Because this report is intended as a nascent standard, we have employed various formal notations for precision.  We have also included commentary in a number of places in fine print.  But the fine print should be viewed as hints about the standard; in any conflict, the normal-sized text is to be considered the correct version.
The casual reader may find the Introduction and Glossary helpful.
1. Introduction
Interscript provides a means of representing editable documents.  This representation is independent of any particular editor and can therefore be used to interchange documents among editors.
1.1 Rationale for an interchange standard
As editors proliferate, being able to interchange documents among them is becoming more and more important.  Customers need document compatibility to avoid being trapped in evolutionary cul-de-sacs without paying the awful price of converting documents from one system to another.
To provide good performance, a typical editor uses a highly encoded representation of a document.  Different editors use different, incompatible representations, and a user can conveniently edit a document only with the editor used to create it.  A program can convert a document from one representation to another.  But N editors will require N(N-1) programs to do direct conversion from each representation to every other representation.
We can reduce the number of conversion programs needed from N(N-1) to 2N by inventing a super-representation.  Now instead of converting directly from editor 1 to editor 2 we convert from editor 1 to the super-representation and from the super-representation to editor 2.  Using two programs is a minor drawback compared to writing N(N-1) programs.
Defining the super-representation correctly is crucial.  To convert documents faithfully from every editor to every other editor, the super-representation must incorporate all of the structures, formats, and content types used by all the real editors.  Furthermore, the super-representation places an upper bound on all future compatible editors; it must therefore accommodate features yet unknown.  The Interscript standard is an attempt to define such a super-representation.
Interscript has been developed by examining what information editors need and how that information can be organized.  It provides an external representation that is capable of conveying the content, form, and structure of editable documents.  The representation has only one purpose: to enable the faithful and efficient interchange of documents among different editors.  We call the Interscript representation of a document a script.
1.2 Properties than an interchange representation must have
An interchange representation for editable documents must satisfy a number of constraints:
Fidelity
Fidelity is the sine qua non for an interchange representation:  Converting a document from an editor's private representation to a script and back again must have no observable effect on the document's content, form, or structure.  It follows that, if anyone is to trust the fidelity of a standard, it must be possible to test whether two scripts are equivalent.
Universality
A script must not be tied to any particular hardware or any particular file format; scripts will be stored and transmitted using a variety of media.
Expressiveness
A script must be capable of describing virtually all editable documents, including those containing formatted text, synthetic graphics, scanned images, animated images, and mixtures of these various modes.
Scripts must record the association between content and form -- margins, leading between lines, fonts, etc.  Both the content and the form of typical documents require a rich value space containing scalar numbers, strings, vectors, and record-like constructs in order to describe items as varied as distances, text, coefficients of curves, graphical constraints, digital audio, scanned images, and transistors.
Many documents have hierarchical structure.  A book, for instance, is made up of chapters, the chapters are made up of sections, and the sections are made up of paragraphs; a page contains a frame, which contains a figure, which contains a caption and graphics; the description of an integrated circuit has levels corresponding to modular or repeated subcircuits.  A script should exploit such structure where it exists without imposing structure where it does not.
Scripts must capture characteristics acquired by indirection.  A set of paragraphs, for instance, may have a common form; changing the definition of the form will change all the paragraphs.  Or a document may be incorporated by reference in several other documents and inherit different characteristics in each.      
Accessibility
The program converting a script to an editor's private representation should be able to tell what parts of the script the editor can use and what parts it cannot.  For instance, even if the editor does not understand figures it might be able to handle the captions in the figures correctly.  And the editor's private representation must be able to preserve the information about the figures so that they can be passed back into a new script and regenerated by more sophisticated editors.  The syntax and semantics of scripts must therefore be simple enough so that they can be interpreted readily, even by very primitive editors. 
Efficiency
Since scripts will be stored, transmitted over networks, and converted, they should take up little space, and converting between a script and the private representations of the various editors should take little time.
Extensibility
The standard should not foreclose future options for documents that exploit additional media (such as audio) or require rich structures (such as VLSI circuit diagrams or database views).  The standard must be capable of incremental extension, and any extension must have the same guarantees and be able to employ the same mechanisms as the rest of the standard.
1.3 What the standard does not do
Interscript is not a file format.  The standard is not concerned with how scripts are held in files on various media (floppy disks, tapes, etc.) or with how they are transmitted over communications media (local area networks, telephone lines, etc.).
Interscript is not a standard for editing.  A script is not intended to be a directly editable representation.  It is not part of its function to make editing easier, more efficient, or more compact; that is the purview of editors and their associated private representations.  A script is intended to be converted before being edited; the conversion might be done by the editor, by a utility program on the editing workstation, or by a completely separate service.
Interscript does not directly help combine documents.  In general, it is no easier to glue two arbitrary documents together than it is to edit them.
Interscript does not overlap with other standards.  For instance, it does not address the issue of specifying encodings for characters in documents or the issue of how fonts should be named or described.
--------------------------------------
�Ê
ò˜JšÏsœ˜Jš�œ˜JšÑprsœ#˜+Jšžœ˜Jšžœ˜J˜Iblockš
œÖ˜ÖK˜J˜š
œ&˜&JšÐbsœ˜JšŸœ˜JšŸœ˜JšŸœ˜JšŸœ˜
Ilead1šÏt
œ(˜)Ilead2˜š
Ïl˜Mš¡oÐil¡á˜ÖMš
¡È˜ÈMš
¡A˜A—š
¡˜Mš
¡¿
˜¿
š
¡)˜)Mš
¡˜˜˜Mš
¡·˜·Mš¡«
Ðls
¡°
˜ÜMš
¡Ý˜ÝMš¡«¢¡
˜²—š
¡;˜;Mš
¡Z˜Zš
¡˜Mš¡¢¡Ï˜ë—š
¡˜Mš
¡”
˜”
—š
¡˜Mš
¡Í
˜Í
Mš
¡š˜šMš
¡Ñ˜ÑMš
¡½˜½—š
¡
˜
Mš
¡ö˜ö—š
¡
˜
Mš
¡Ù
˜Ù
—š
¡
˜
Mš
¡é˜é——š
¡!˜!Mš
¡ù
˜ù
Mš
¡Ñ˜ÑMš
¡”
˜”
Mš
¡Ë
˜Ë
———Jš
œ&˜&—…— ô"ì*start*
01263 00097 US 
gvMsgID: Ayers.PA $ 60#91@22-Jan-84 13:03:44 PST
Categories: InterScript
Date: 22 Jan 84 13:03:44 PST (Sunday)
From: Ayers.PA
Subject: Re: Alternate Interscript Introduction
In-reply-to: Horning's message of 20 Jan 84 15:30:57 PST
To: Horning
cc: Mitchell, Ayers

I agree that it will be easier to clear exactly what we cleared before. 

Since we actually handed out the previous version in public, it's hard to see how the blue&white can fail clearance -- after all, if someone at ANSI could reprint it, surely we can!

I liked all of the vanLeunen introduction except for 

    A script is intended to be converted before being edited; the 
    conversion might be done by the editor, by a utility program on 
    the editing workstation, or by a completely separate service.
    
this is because I don't like the word "convert" in this context. I claim that a script cannot be "converted" by "a utility program" or "a completely separate service" because those would be information-losing conversions. It could be converted by, say, a "extension of the editor running as a separate module, perhaps even on another machine."

Bob

PS: Either of you interested in a short-term as-required consult-on-Interscript-language-issues contract?
*start*
01170 00099 US 
gvMsgID: Horning.pa $ 3#203@23-Jan-84 13:05:22 PST
Categories: InterScript
Date: 23 Jan 84 13:05:24 PST
From: Horning.pa
Subject: Re: Alternate Interscript Introduction
In-reply-to: "Ayers' message of 22 Jan 84 13:03:44 PST (Sunday)"
To: Ayers
cc: Horning, Mitchell

Bob,

The same document may be represented by

	a) a script,
	b) an editor's internal format (after internalization),
	c) an editor's file format (after internalization and storing)

There is no reason in principle why a completely separate service could not perform the transformation from a) to c) without ever involving the editor itself. The fidelity of the transformation would be limited by the capabilities of the editor's file format, not by which program does the conversion.

I'm available as a short-term as-required Interscript-language-issues-consultant for the rest of the week. Beyond that would have to be negotiated between Xerox and Digital; I have no personal objections, and will raise the question with Bob Taylor next time I see him. 

Jim H.

�Êj˜JšÏsœ˜Jš�œ˜JšÑprsœ'˜/Jšž�
œ3˜@Jšžœ˜	Jšžœ˜J˜Iblockš
œõ˜õK˜—…—À0*start*
00955 00097 US 
gvMsgID: Ayers.PA $ 60#91@23-Jan-84 13:41:16 PST
Categories: InterScript
Date: 23 Jan 84 13:41:18 PST (Monday)
From: Ayers.PA
Subject: Re: Alternate Interscript Introduction
In-reply-to: Horning's message of 23 Jan 84 13:05:24 PST
To: Horning
cc: Ayers, Mitchell

I agree with your description:

    The same document may be represented by

	a) a script,
	b) an editor's internal format (after internalization),
	c) an editor's file format (after internalization and storing)
	
It's just that I am bother by the two words:

     "Conversion" because it seems akin to what we do today in
     the standard information-losing way and
     
     "Separate" because it could imply that the "separate service" 
     can function without knowing the editor's (private) nonstandard
     representation(s); the word stood out because it was a part of 
     "completely separate," which accentuates the above.
     
No big deal ...

Bob  

*start*
01930 00097 US 
gvMsgID: Ayers.PA $ 60#91@23-Jan-84 14:34:16 PST
Categories: InterScript
Date: 23 Jan 84 14:34:20 PST (Monday)
From: Ayers.PA
Subject: SGML-Interscript Comparison Chart
To: Pierce.dlos
cc: Rowe, Elkind, Ayers, Mitchell

Steve, I received the "comparison chart" today. [Bhushan gave me a copy; then the telecopy finally arrived!]


I find it misleading and downright wrong.

    a. The "functions" listed are so broad and ill-defined that its 
       hard to say "No."
    b. I don't believe the statements.

For example, here are some alternate answers:

      Function                SGML                Interscript
  
   2. Layout Structures       No !                Yes
   3. Human Features          Yes                 Yes - "Publication Encoding"
   6. External References     Yes                 Yes - via "Environment"
   7. Environment/Scope       Yes but informal    Yes - precise
   8. Syntactic Diff'ion      Yes                 Yes
   9. Imbedded Unknown Data   Only as unparsable  Yes, part of standard
   
I do not believe that SGML has "layout structure" or any other form of real geometric layout.

You do not have to convert anything to "Interscript notation" to imbed an unknown node type in Interscript -- an arbitrary byte-sequence is perfectly good node content.

And here are some comparisons that weren't made:

      Function                 SGML                  Interscript
  
  11. Formally Defined         No                    Yes
  12. Simple Basic Syntax      No                    Yes
  13. Geometric Layout         No                    Yes
  14. Styles                   partly                Yes
  15. Document Equivalence     No                    Yes
      Defined
  16. Complete Document        No, requires inter-   Yes
      Description              preter language(s)
      

[You might forward this to the other people who received the comparison.]

Bob
   





*start*
00928 00100 US 
gvMsgID: mitchell.pa $ 3#211@24-Jan-84 14:43:41 PST
Categories: InterScript
Date: 24 Jan 84 14:43:46 PST
From: mitchell.pa
Subject: Interscript at X3J6 
To: Ayers
Cc: mitchell, Bhushan.wbst, Ritchie, Elkind

Bob,

Here are our reservations for going to the X3J6 meeting in Anaheim tomorrow to present Interscript:

7:30am: meet at the building 96 parking lot
8:55am: take PSA688 to Orange County airport
10:00am: arrive at Orange County airport, get Hertz car and drive to Ramada Inn, Anaheim
10:30am+: meet Ed Smura in lobby of Ramada Inn

1:00pm: I give talk on Interscript (~2 hours), followed by discussion
5:30pm (at the latest): leave Anaheim to catch flight back
6:25pm: take PSA699 back to SFO (arrives 7:38pm)

We should be back at SDD by 8:45pm (could still fit backgammon in).

See you tomorrow morning.

--Jim

�ÊK˜Jš
œ˜Jš
œ˜JšÐbsœ˜Jš�œ˜	Jš�œ)˜+J˜J˜æ—…—ì=*start*
08277 00099 US 
gvMsgID: talbot.rx $ 100#18@25-Jan-84  9:34:04 PST
Categories: InterScript
Date: 25 Jan 84 17:28:53 GMT (Wednesday)
Subject: ECMA TC29
To: SRowe.pa
cc: Talbot, Wheeler.wbst, Pierce.dlos,Ayers.pa, Mitchell.pa, Elkind.pa, JWhite.pa, Blake.rx, Bulnes.pa, Lynch.pa, Hutchinson.rx, Cooper.rx,Englund
From: John Talbot <Talbot.rx>

Steve,

we missed you off the distribution list for this report, for which I apologise.  

As you are aware both Martin Gittins and Martin Cooper were there, and Martin Gittins did in fact offer to the chairman that Xerox would be prepared to send someone to the next session to talk about interscript.  The response was not overwhelming, which is probably understandable, as they really do not know about it.

What I propose we do, is to circulate the new interscript document to ECMA now, as a "concepts for possible inclusion in the future standards" document.  Secondly about two weeks later, when they have had time to realise that it is not just a light novel, we should make an offer to have someone from Xerox come to the  26-30 March session of ECMA.  We only have third generation copies here, so if you agree to sending this out, we need pointers to files.

On a second topic, Martin Cooper has been asked by Horak of Siemens, to attend the ISO meeting on the same subject.  This is the ISO TC97/SC 18 Working group 3, looking at Text Preparation and Interchange.  Roy Pierce has said he thought that it would be a good idea if Martin Gittins were to attend.  Martin Cooper has discussed the matter with Ian Campebell-Grant of ICL, who is the BSI representative on this committee, and it is no problem to get him.

I am prepared to send Martin Cooper if you agree that it makes sense to do so.

~ John

----------------------------------------------------------------
GVInfo: Cooper.rx, from 144#67, at 19-Jan-84 10:15:45 GMT
Date: 18 Jan 84 19:07:02 GMT (Wednesday)
From: Cooper.rx
Subject: Report on ECMA TC29 Meeting, 9th to 13th Jan 84
To: Talbot.rx, Wheeler.wbst, Pierce.dlos
cc: Ayers.pa, Mitchell.pa, Elkind.pa, JWhite.pa, Blake.rx, Bulnes.pa, Lynch.pa, Hutchinson.rx, Cooper.rx
Reply-To: Cooper.rx

    Last week (9th to 13th January), I attended the 7th Meeting of ECMA TC29 in Geneva, replacing Martin Gittins, who has left the company. Aside from the usual administrative tasks of the committee, several important issues were discussed. I shall present these in some detail here, and so wish to apologise now to those of you not interested in such details. Please feel free to disregard those parts in which you have no interest.

    The first paper to be considered in depth was the CCITT Draft Recommendation S.a (Document Interchange Protocol for the Telematic Services), and this was discussed in the light of contributions by L J Zeckendorf (Phillips), L Durand (Cii-HB) and others. As a result, several formal comments are to be submitted on S.a. The main points of these are:
  1) Inefficiency in the format of object and content portion identifiers - changes have been proposed to overcome the problem.
  2) Usage of the term, and optionality of, the Document Profile (Document Description).
  3) Direction of measuring angles - the document is inconsistent in this respect, and it is proposed to measure these in a clockwise direction.
  4) Default value of initial offset - changes to reflect the changes made in 3 above.
  5) Inconsistencies exist in identifiers for tagged data types, for which no explanation can be found.
  6) The concept of subarchitectures has been lost in the generalities of the document and should be reintroduced.

    Next the committee discussed CCITT Draft Recommendation X.420 (Message Handling Systems). Comments were submitted on this work by experts from Siemens, Cii-HB and ICL, being the results of a collaborative study. These comments were discussed at length, and it was decided to submit comments from ECMA to CCITT in general terms, in order not to disrupt too greatly the progress of the X.420 proposal. Moreover, it is suggested that such a Recommendation would lead to incompatibilities with extensions of Recommendation S.a as foreseen.

    The third and most significant discussion was on the Office Document Architecture, Fifth Working Draft (Proposed) submitted by BSI. Contributions were submitted by W Horak (Siemens), L J Zeckendorf (Phillips) and others. A series of proposed amendments are to be presented for consideration at the meeting of ISO WG3 in Geneva in February of this year.
    Several major changes are being proposed which significantly increase the flexibility of the ODA, and in a direction which increases the likelihood of compatibility with Interscript. Many of the new ideas were born in the large and detailed contibution submitted by W Horak of Siemens, and were strongly supported by myself. These include the introduction of Generic Object Definitions, which define an object class by means of rules to determine composition, content, etc., and Generic Attributes, which are rules to determine the attributes of an object of the class. Most importantly, these rules allow values to be determined by expressions evaluated in a context dependent manner, rather than simply by constants.
    During this discussion it became apparent that the efforts of Rank Xerox and Siemens had to be combined in order to propose and explain these ideas and gain their acceptance by the committee. For this reason, Mr Horak requested my support at the ISO WG3 meeting at which these coments are to be presented. I myself feel that this would be beneficial, perhaps even necessary, in order that the ideas which we propose should be accepted by ISO.

    Subsequent to these discussions, the future activities of the committee were discussed. Since TC29 is to submit a draft standard for consideration at the ECMA General Assembly in December of this year, and since the deadline for such submissions is August of this year, it is clearly essential that a draft be finalised as soon as possible. However, the committee agrees that work on future development and enhancement should not be suspended while this is done. It was therefore decided that TC29 should, if possible, be divided into two Task Groups, in order that the two activities may be carried on in parallel. The proposed Task Groups are a Short Term Task Group (TGS) to finalise the draft standard, and a Long Term Task Group (TGL) to develop description methods for rules, expressions and generic definitions, and other subjects for further study such as subarchitectures.
    One important consequence of this decision is that two representatives of each company will be required to monitor both Task Groups. Some companies less involved in this field (eg GEC and Ferranti) may not be able to provide two representatives, whereas others (eg Siemens and ICL) have promised the required numbers. After a private discussion between Mr Horak and myself, we decided that it would be useful if one of us sat on TGS and the other on TGL. Since Mr Horak expressed a strong desire to sit on TGS, this would suggest that a second representative of Rank Xerox, to sit on TGS, will be required. In the light of last week's meeting, I would suggest that the proposals and comments made by Siemens and Rank Xerox will not be accepted without representatives of each company in both Task Groups.
    I should point out that the division of TC29 into TGS and TGL, working in parallel, may not actually occur, and is dependent on the provision of sufficient representatives from the companies concerned. However, I feel that this move would benefit all concerned, in that future developments will not be retarded by time spent producing a draft standard.

    The future meetings of TC29 which were arranged in Geneva last week are as follows:

  26th to 30th March 1984, Geneva
  Organise the committee into the two Task Groups, and work as TGS and TGL.
  
  14th to 18th May 1984, Munich
  Work only as independent Task Groups (possibly only TGS - to be decided later).
  
  25th to 29th June 1984, Amsterdam
  Initially work as TGS and TGL, then combine to discuss final standard.
  
  
  
  
      Martin F N Cooper

----------------------------------------------------------------
*start*
06054 00097 US 
gvMsgID: Ayers.PA $ 60#91@26-Jan-84 21:55:01 PST
Categories: InterScript
Date: 26 Jan 84 21:55:00 PST (Thursday)
From: Ayers.PA
Subject: Re: Comparison Chart
In-reply-to: PIERCE.DLOS's message of 25-Jan-84 14:56:17 CST
To: PIERCE.DLOS
cc: Ayers, Rowe, Jacobson.dlos
cc: Mitchell, ALBrown, ESmura.es

Roy, you asked for a "1 to 3 page technical document that provides the differences/advantages of Interscript over SGML". Here is an initial cut.

If you are going to be available on Monday, let me know and I will try to make it better over the weekend.



                  Interscript and SGML: a Comparison

Introduction

   We will compare and contract Interscript and SGML both as to their
   intended uses and their success in meeting their goals.
   
   The Interscript we discuss is the one defined in the Interscript Draft
   Standard of January 1984. The SGML we discuss is the one defined in part
   six of "Computer Languages fot the Processing of Text" 15 June 1983
   by 97.5.12/EG CLPT(X3J6).
   
   This comparison stays at the basics of the two draft proposals, and avoids 
   discussing detailed issues, such as who supports what data types. These
   details, which quite important in any real standard, are often 
   amenable to correction through simple augmentation (the 'bandaid');
   it is the underlying basics that determine whether the standard is on 
   a sound footing and thus capable of supporting an evolving standard, 
   or whether it is (or will become) "one damn things after another" -- a
   patchwork of rules and exceptions that sinks of its own weight. 
   
Document Specification

   Both Interscript and SGML allow one to describe a document in terms of 
   its logical content: sections contain paragraphs which contain words.
   
   They both also allow one to describe a document either in the concrete:
   an actual document instance, or in the abstract: the "generic" document, 
   which describes the possible document constituents and their legal
   structuring.
   
Formal Language: Origins

   Both SGML and Interscript provide a formal language upon which one can
   build a semantics to capture meaning.
   
   The SGML syntax has been evolved from the "document markup" approach
   of early document formatting systems, where users entered explicit
   codes (typicially distinguished by "a period in column one"), separate
   from the body-text, which controlled document formatting.
   
   These markups were extended by noticing that specific formatting
   instructions (insert double space) could be replaced by document
   part identifications (new paragraph), which would allow formatting 
   to be adjusted depending on the desired output style. The document
   part identifications were then evolved into a formal system for
   stating the constituents of the document. 
   [See SGML reference pp 81-88 and 1-2].
   
   The Interscript syntax was defined based on a rigorous formal-language 
   syntax. This syntax was originated AFTER a detailed investigation into 
   the fundamentals of document structure, and tailored to the observed
   nature of documents.
   
Formal Language: Syntax and Semantics 
    
   The SGML syntax is defined on pages 9-51 (informally) and 52-77 
   (formally, via 83 production rules) of the SGML reference.
   
   Interscript syntax is defined in one page of BNF.
   
   SGML semantics is defined in the English prose that accompanies the
   syntax on pages 9-77.
   
   Interscript semantics is defined, formally, as a function defined
   over the the set of parse trees corresponding to the abstract syntax.
   It is expressed in six pages of formal definitions.
   
   The differences in formality and in compactness are obvious.
   
Formal Language: Differences in Capabilities

   Both SGML and Interscript offer the capability of expressing a quite-
   complicated document structure. Both can express the structure of a 
   document instance or of a generic document.
   
   Both offer a human-readable representation, although I do not attach
   much weight to this.
   
   Interscript offers a formal scoping of bindings (assignements of values
   to names); SGML lacks this, using a combination of local assignement
   and predefined 'defaults.' 
   
   Interscript offers formal "abbreviation" and "style" mechanisms. 
   SGML offers an "entity" mechanism which does not distinguish between 
   abbreviation (used for compaction) and styles (used to achieve an
   'indirection' so that the attributes of a number of elements can
   all be changed at once).
   
   Interscript offers a way of formally stating that two document scripts 
   are "equivalent." That is, it defines what it means for two documents 
   to be "the same" while, perhaps, not being bit-for-bit identical.
   This is CRITICAL for being able to define the editing process. 
   (Did the editor change the document or not?). The notion of equivalence
   is absent from SGML.
   
Document Semantics 

   Both Interscript and SGML define a basic syntax and semantics, which,
   at bottom, really have nothing to do with actual documents.
   The syntax, for example, lets you talk about "chapters" or "paragraphs"
   (saying such things as 'every chapter must contain at least one
   paragraph') without really saying anything about what a paragraph IS.
   
   SGML stops here. 
   [The SGML reference corresponds to sections 1-3 of Interscript.]
   
   Interscript continues to define the actual document semantics of several
   "node types."

Layout in the Document Semantics
   
   Among the key node types that the Interscript Standard formally defines
   is the BOX, which is its basis for document layout.
   
   Interscript defines a precise geometrical model of page layout, 
   including both generic layout (the page dummy) and concrete layout 
   (actual page-instance geometry). It incorporates a precise definition
   of how the "logical structure" of section/paragraph/word is mapped 
   into the layout structures of page/column/line.
   
    
*start*
00523 00097 US 
gvMsgID: Ayers.PA $ 60#91@27-Jan-84  9:34:16 PST
Categories: InterScript
Date: 27 Jan 84 09:33:26 PST (Friday)
From: Ayers.PA
Subject: Things-To-Do-Before-Leaving
To: Mitchell
cc: Ayers

Exact Interscript material that was given to ANSI:

    I would appreciate it if both the Tioga and the Press versions of 
    your part of the material was put onto a file server.

Interscript slides from ANSI presentation:

    I would appreciate it if the Press versions were put onto a file server.
    
Bob
*start*
00647 00100 US 
gvMsgID: mitchell.pa $ 3#211@27-Jan-84 12:16:29 PST
Categories: InterScript
Date: 27 Jan 84 12:16:36 PST
From: mitchell.pa
Subject: Re: Things-To-Do-Before-Leaving
In-reply-to: "Your message of 27 Jan 84 09:33:26 PST (Friday)"
To: Ayers
Cc: Mitchell

Bob,

All the Interscript stuff is on [indigo]<Interscript>

The df file that contains Tioga and the Press versions of my part of the material and the ANSI slides is [Indigo]<Interscript>DraftStd>interscript-Std.df.  I believe the file names in there are self-explanatory.

--Jim

�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ!˜(Jš�œ3˜>Jš�œ˜	Jš�œ
˜J˜J˜˜—…—
Ê$*start*
00925 00100 US 
gvMsgID: mitchell.pa $ 3#211@27-Jan-84 12:24:00 PST
Categories: InterScript
Date: 27 Jan 84 12:24:06 PST
From: mitchell.pa
Subject: Re: Comparison Chart
In-reply-to: "Ayers' message of 26 Jan 84 21:55:00 PST (Thursday)"
To: Ayers
Cc: PIERCE.DLOS, Rowe, Jacobson.dlos, Mitchell, ALBrown, ESmura.es

Bob,

I think your analysis of the comparison between Interscript and SGML is right on the money.

After the meeting in Anaheim the other day with the (rather vocal -- if you only count volume) four people still designing SGML, I feel very confident that Interscript is far and away a much better basis for a standard.  SGML is a hodge-podge of features, is barely readable, and has almost totally ignored known techniques for developing and expressing the precision that such a standard needs.

--Jim Mitchell

�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ˜Jš�œ7˜BJš�œ˜	Jš�œ@˜BJ˜J˜ÿ—…—à:*start*
02178 00098 US 
gvMsgID: ESMURA.ES $ 44#35@27-Jan-84 14:15:12 PST
Categories: InterScript
Date: 27 Jan. 1984 2:15 pm PST (Friday)
From: ESMURA.ES
Subject: TC 97/SC5/WG12 (X3J6) Meeting
To: Ayers.PA, Mitchell. Pa
cc: PIERCE.DLOS, Bhushan.WBST, Wheeler.WBST, Szelong, ESMURA

Thank you very much for your presentation to X3J6 at Anaheim on Wednesday.
It was very well received. May I now have a copy of your slides so that I can
distribute it along with your Interscript document to members of the Print
Standards Subcommittee - they requested same after I made my verbal report
Thursday.

I also want to pursue Jim Mitchell's recommendation that we prepare a chart or
two on document interchange goals and present it to X3J6 at the May meeting -
hopefully with instances of editable scripts and how and why one might use
these instances during document interchange. This is very important if we want
those doing Parts 3, 4, and 5 of the standard to embrace Interscript concepts.

In talking to those doing Parts 3, 4, and 5 (and Card the convenor) they really
welcome Bob, to help (or steer as I say) them move into the future and run away
from yesterday - what Goldfarb is doing. They all realize the requirement for
backward compatibility and the need to continue with Part 6, but know as well
that the language(s) standard also deals with integration of functions and making
the task of creation and interchange less cumbersome tomorrow.

There is no doubt in my mind, but that the forthcoming standard will
eventually embrace Interscript if Xerox people like Bob will help a bit. The
danger as I see it lies in someone from Part 6 becoming Chairman of X3J6. Card
cannot, I believe, continue to be Chairman of X3J6 and convenor of SC5/WG12.
If the Chair goes to Bill Davis (IRS), the new standard will be silent on many
aspects of document interchange and worse yet become  "one damn things after
another" -- a  patchwork of rules and exceptions that sinks of its own weight, as
Bob says.

ED

PS
Card suggested a less formal document, something like the presentation to
demonstrate the concepts -- help generate enthusiasm and gain RAPID support.
What do you think?

*start*
00435 00098 US 
gvMsgID: ESMURA.ES $ 44#35@27-Jan-84 14:19:18 PST
Categories: InterScript
Date: 27 Jan. 1984 2:20 pm PST (Friday)
From: ESMURA.ES
Subject: Re: Comparison Chart
In-reply-to: mitchell.pa's message of 27 Jan 84 12:24:06 PST
To: mitchell.pa
cc: Ayers.pa, PIERCE.DLOS, Rowe.pa, Jacobson.dlos, ALBrown.pa, ESmura

I agree, but you forgot to mention the majority of guys who were not at high
volume and LISTENED.

ED

*start*
00297 00097 US 
gvMsgID: Ayers.PA $ 60#91@29-Jan-84 14:12:10 PST
Categories: InterScript
Date: 29 Jan 84 14:12:10 PST (Sunday)
From: Ayers.PA
Subject: Late Queries: Interscript Blue&White
To: Mitchell
cc: Ayers

Horning and you apparently started this happening. Who is coordinating?

Bob
*start*
00605 00100 US 
gvMsgID: mitchell.pa $ 3#211@29-Jan-84 23:15:17 PST
Categories: InterScript
Date: 29 Jan 84 23:15:14 PST
From: mitchell.pa
Subject: Re: Late Queries: Interscript Blue&White
In-reply-to: "Your message of 29 Jan 84 14:12:10 PST (Sunday)"
To: Ayers
Cc: Mitchell, Subhana

Bob,

If you will get camera-ready copy (i.e., high quality printout) to Subhana in CSL, she will put it with some that I will give her for my part of the Interscript report, and then she can make it a Blue&White.

--Jim
�ÊT˜Jš
œ˜Jš
œ˜JšÐbsœ*˜1Jš�œ3˜>Jš�œ˜	Jš�œ˜J˜J˜Ü
—…—
 
ú