🚀 go-pugleaf

Darrell Raymond writes:

>  My claim is that this sort of thing can happen again in document systems,
>even though they be SGML-conformant.  I think this is the down side of
>making too much use of structure which SGML cannot validate or enforce.
>I think that the very point where this becomes an important issue is when
>SGML is used to describe things that aren't just hierarchical documents,
>as was suggested by Travis's posting (and by the earlier work of Rubinksy,

Darrell's point is well taken, and I think comes right down to the
question I asked in my longer posting?  Given that what Darrell says
may be a problem is, how do we solve it?  I've already run into the
problem that describing the semantics of data interrelationships
in a document architecture is difficult and realized immediately
that an application that did not understand those relationshi\s
would not process the document correctly, because without an
understanding of those relationships, typical assumptions made
about documents would not, in this case, be true.  My solution
was to make support for that part of the architecture optional
(with a corresponding required usage declaration ala HyTime) so
that conforming systems would not be required to support a complex
semantic (thus enabling existing but simple systems to be made
conforming with minimum effort) and so that simple systems would
know up front that a document required processing they couldn't
provide.

Also, in my work creating a complex document processing system
that transforms documents created for a single primary target
(print) into a very different form, we were forced, for
pragmatic reasons, to make a lot of assumptions about the content
and those assumptions bite us all the time.  We do not have
the luxury of retrofitting our sematic requirements onto an
existing database of legacy documents.  Our immediate solution
is to eat the document rework cost and try to add as much error checking
to our code as possible, which is very expensive (but still cheaper
than not having the processor at all).

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