A STRUCTURED MODEL OF STRUCTURED MODELING

My starting point here is a Structured Modeling rendering of the core and non-core definitions in my paper "The Formal Aspects of Structured Modeling," Operations Research, 37:1 (January-February, 1989). This representation is particularly useful for seeing which definitions depend on which other(s), and it also serves as a reference work on the most important terms used in Structured Modeling.

This model is written in Level 1 SML. There are no Elemental Detail Tables.

How to render this model as a Web document is far from unique. Here I offer three possibilities, one at each end of a certain obvious spectrum and one in the interior. My intention is that by evaluating all three, one can better understand how to render a Level 1 Structured Model as a Web document. This should also inform the rendering of models written in Level 2, 3, and 4 SML.

Although this exercise is useful for its own sake, it is also a beginning toward a grander ambition: devising a SM-based method for writing many types of Web documents that will yield many of the advantages of Structured Modeling.

Here are the three versions (paragraph indentation displays incorrectly for Versions 1 and 2 in browsers that do not accept nested blockquote tags as Netscape does):

 
• Version 1 (monolithic)
• Version 2 (lightly fragmented)
• Version 3 (fully fragmented)

The monolithic version puts the entire model in a single Web page. (Modules never trigger a new Web page.)

The lightly fragmented version puts the model in a root Web page plus one Web page for each of the three first-level modules. (All and only the first-level modules trigger a new Web page.)

The fully fragmented version puts the model in a root Web page plus as many additional Web pages as there are modules. (Every module triggers a new Web page.)

Obviously there are many possible degrees of fragmentation between Versions 1 and 3 depending on when a module triggers a new Web page. Among these, Version 2 is only one example.

All three versions use the same style for representing a genus or module paragraph:

• The formal portion is boldface, just as in SML.
• Every calling sequence component is rendered as a "hot" link back to the defining paragraph.
• In the informal portion (the interpretation), each defined key phrase is rendered in green caps (the color is evident only with browsers that support the "font color='green'" tag) rather than in underlined caps as in SML; and each referenced key phrase is rendered as a "hot" link in caps back to the defining paragraph.
• The paragraph retains the short reserved words of "native" SML rather hiding them as in SML as usually written and in FW/SM. They terminate the formal part of each paragraph (~|), terminate the paragraph itself (~.), and delimit defined key phrases (~/). These reserved words greatly facilitated conversion to HTML, and could easily be removed but are retained to facilitate further stylistic experimentation (and to mark defined key phrases for browsers that cannot show these in green). They can be ignored.

• Hot-linking each calling sequence component and referenced key phrase to its defining paragraph is a nice feature beyond what is possible in a printed rendering of the model or in FW/SM (although a crude implementation of hot links is possible through Framework's abbreviations feature). A reader who forgets the meaning of a genus or module name upon encountering it later in the model is only one click away from seeing the full definition. But this useful feature comes at a price, as mentioned next.
• Making a hot link out of each calling sequence component and referenced key phrase disfigures the display because Web browsers indicate hot links by putting them in color (at least some browsers do) and underlining them. It would be nice if the underlining could be turned off, and perhaps the color too; perhaps this capability will be added to a future version of HTML or to some browsers. Hot links would then be evident only by the URL displayed when the cursor is on it. Alternatively, hot links could be displayed in a close color variant of the normal typeface color (e.g., in gray if the normal color is black).
• I like Version 1 the best and Version 3 the least because it makes better use of my screen and makes it easier to navigate the whole model. But I recognize that this conclusion is somewhat specific to the present application. For example, I would not want the INFORMS Policy & Procedures Manual to be rendered monolithically; I would want the ability to hide and reveal portions per the outline of the manual.
• The prior point suggests an interpretation of hot-linking: it enables portions of a document to be hidden and revealed at will. The problem is that present versions of HTML do not (to my knowledge) permit the hiding and revealing to be done within the visible context of the page to which a subpage is linked: the display always jumps to the subpage and erases the page containing the link. Of course, there are other ways to add the capability to dynamically expand and contract the current page per the contents of a subpage when this new type of link is clicked. In effect, this would be a kind of outlining capability. It would be valuable for hierarchically organized documents like an SML schema, where module paragraphs could make good use of it (not so for genus paragraphs).