🚀 go-pugleaf

In article <9207201503.AA25149@ucbvax.Berkeley.EDU>, DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro") writes:

>I do know that I have yet to be presented with a data form or 
>set of relationships that I cannot express in an SGML tag set 
>coupled with complementary processing applied to that tag set.  

  Two comments.  First of all, computationally speaking, this isn't 
saying much.  For if you allow yourself to use complementary processing, 
then it doesn't matter *how* you express the original relationships, or
which ones you do specify.  For you can smuggle all the complexity, as 
well as any extra relationships you want, into your complementary processing.
If you start out with arbitrary computing power, it's not surprising that 
you end up being able to do anything that's computable.

  However, we now have to consider problems of interchange, portability,
and separation of concerns for the complementary processing.  I assume 
(correct me if I'm wrong) that you express this complementary processing 
with a custom program that manipulates the tags to do something.  How do 
you intend to ensure that this custom program, and all the relationships 
it includes, are usable at another SGML site?  And if it is not, isn't it
fair to say that SGML hasn't really expressed this information?

>I'm not a computer scientist in the formal sense, and I'm certainly
>not a mathematician, but it is very difficult for me to believe
>that there are data types and relationships that cannot be
>expressed in an SGML tag language.  

  I think this is because you are counting on arbitrary complementary 
processing to express any relationships that can't be expressed in the
content model.  But, as I've suggested above, this is an escape hatch 
that works two ways - it allows anything to be expressed, at the cost 
that you have no way of restricting the expression to something that 
other sites can understand.

>There are certainly
>relationships that cannot be expressed in an SGML content
>model, but that is not the same thing, because content models
>are not the only way that data relationships are definable in
>SGML.  

  There is a basic lesson from database practice: express relationships
in the data model, and keep them out of the applications programs, or
else you will build something you eventually can't understand, since so
much of the semantics will be bound up in applications packages. If
SGML provides no way to communicate the structure of this complementary
processing, then parts of the data model are being buried in applications.

-Darrell.