🚀 go-pugleaf

References: <118460002@hpcupt3.cup.hp.com> <22747@ilog.fr>

Jim McCauley writes:

>Since SGML involves some level of _structural_ description, how might
>it be used to indicate structural changes to a document?  For example,
>if the sections in a chapter are reordered, how might that "delta" be
>encoded in SGML?

I don't think you could encode it in SGML in the document (except as
structured comments) if your logical document structure is only defined
by the structure implicit in the markup itself.

However, if the logical structure is defined separately from the markup
structure, you have a level of indirection that gives you a place to
store and capture changes.  In other words, instead of having the
markup define the logical document hierarchical tree, you have one
set of elements that defines the hierarchical tree and another set of
elements that contain the actual content to which the tree defining
elements refer.  In other words, the logical document structure is
defined by a tree of pointers that point to the actual content elements
to used at each node of the tree.  I can do this with IDREF elements
using the content extraction semantic defined by HyTime.

For example, I might define the atomic unit of logical organization in my
DTD to be to divisions (headings).  Each division points to its content
(paragraphs and other stuff divisions might contain) using a content
extraction link (in HyTime terms).  My document instance consists of
two parts, the first part consisting of nothing but headings, the
second part containing the objects the headings reference:

<!ELEMENT doctype - - ( HeadingContainer+, ContentContainter?) >
<!ELEMENT HeadingContainer - - ( Division+ ) -- Contains only divisions -->
<!ELEMENT Division         - O ( ContentRef | Division)*
                                  -- Content obtained only by reference--
>
<!ELEMENT ContentContainer - - (%content.elements;)* -- Paragraphs etc. -->

<!ATTLIST ContentRef HyTime NAME #FIXED "clink" -- Conforms to clink AF --
                   linkend IDREF #REQUIRED    -- Content location.    --
                                          -- Could be nameloc element --
>
<!ELEMENT ContentList  - - ( nmlist | nmquery)* -- HyTime nameloc AF -- >
<!-- Refers to HyTime nmlist and nmquery architectural forms  --
  -- nmlist contains a list of IDs or entity names, nmquery is a --
  -- query in some implementation-specific query language that   --
  -- results in a list of IDs or entity names.                   --
<!ATTLIST ContentList  Hytime NAME #FIXED "nameloc">

Note that the content model for doctype allows multiple
HeadingContainer elements.  Each HeadingContainer could represent a
different logical organization of my document, allowing me to define
and capture each new revision.  A "diff" of two container trees would
reveal the differences from one revision to the next.  Alternatively,
I could use a single HeadingContainer and use marked sections or
define property attributes and use property references to retrieve
different versions (e.g., <division version="10/92">)

Granted, this isn't a very direct way to encode documents, but a
reasonably-sophisticated authoring system shouldn't have any difficulty
managing the indirection.  Also consider the case where the content
objects are not actually in my document, but are accessed by external
reference, say from some corporate document object database.  This is,
for example, the way you might structure the definition and retrieval
of multimedia documents that are both highly dynamic and draw from a
large database of re-used objects.

Note also that all of my indirection uses SGML elements and
hyperlinks, not entities.  This means that the indirection and
reusability is completely independent of the details of entity
structures, and thus is not dependent in any way on the organization
of the source files, something SGML has little or no control of.

Note also that HyTime defines all the processing and linkage semantics
I need to implement this example (as evidenced by my use of HyTime
architectural forms).

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709