🚀 go-pugleaf

References: <22747@ilog.fr>

William Skyvington writes:

> My question is no doubt naive, because I'm a newcomer to SGML.
>
> I'm curious to know how change bars should be handled in a
> politically-correct SGML manner....

This is, as Erik said, a tough nut.

The approach I'm taking is that things like revision status, level,
version, etc., are properties of elements, and are thus carried as
metadata (see my article in the August <TAG> on attributes and
metadata), specifically, as attributes.  By doing this, you separate
the description of the property from any particular expression of it
(e.g., change bars) and you remove the need for sequential processing
of your information to correctly find boundaries of the sort defined
by a <REV START> <REV END> construct.

Say we have, for example, an attribute for all elements called
"REVISIONS=", defined like so:

<!ATTLIST %allGI; revisions IDREFS #IMPLIED -- points to revision
                                               definition elements -->

(The revision definition elements would define the details of a given
revision (say date, reason, author of the revision, related
documentation like change requests, etc.).)

An online system can now enable a query function that shows
all elements that match a particular revision.  It could generate
a list or simply suppress all elements that don't match.  Likewise,
an authoring system could manage the revision information in
an object-oriented way, rather than having to track the beginning
and ending of revision markers that might cross element boundaries.
A print system would simply generate the formatting controls
needed to get the rev bars for each new revised element.  The
visual effect would be identical to using marker elements.

More complex conditional processing can be handled the same way,
especially if you define in your application rules for property
inheritance (for example, all children inherit the relevant
property values of their parents).  Note that ISO 8879 does not
define such inheritance.  Note also that the processing application, not
the SGML parser, has to provide the processing semantics to do
useful things with the property values.

Like Erik, I've used marked sections to do conditional processing.
It works, but it can be difficult for authors to manage "by hand".
Note that one of the features of SoftQuad's Author/Editor product
that really impressed me is its direct support for marked sections
managed by parameter entities.  A/E provides an interface for
defining parameter entities for use in marked sections and then
uses the values of those entities to display or suppress
marked sections during editing.  This is a really nice function.

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