Re: Richmail & Idraw

[Jonathan Rosenberg <jxr@xxxxxxxxxxxxxxxxxxxx>]

Date: Thu, 13 Jun 1991 13:31:24 -0400 (EDT)
From: John C Klensin <KLENSIN@infoods.mit.edu>
Subject: Re: Richmail & Idraw

> I've been silent about this because I've been overwhelmed and because 
> it is an issue I know little about.  However, with the understanding 
> that we've done a lot of work in using SGML as an interchange model for 
> very complex structured data, one caution about adopting an SGML model:
> especially if any kind of minimization is used, it tends to not nest
> well: low-level element definitions tend to have a lot of knowledge 
> about their environments.

Certainly any simple application would not allow ay kind of minimization
or short reference entities.  This can be disallowed in the system
definition or whatever it's called that describes things about the
application: syntax mapping, legal character sets, max identifier
length, etc.

I don't understand your comment about "not nesting well" at all.  Can
you be more precise?  Are you thinking of entity definitions, inherited
atribute values (I forget their SGML name) or something else?

> This is, of course, not a problem if one promises to never try to use 
> Nathaniel-mail to transport an SGML document,

That certainly isn't the purpose of RichMail (or whatever its new name
will be).

> but that is, of course,  the very first thing some of us would try to do.

I can't imagine why.  I certainly wouldn't think of submitting an
arbitrary SGML document to an arbitrary SGML system.

> In a way, the need for  SDIF is symptomatic: with a different SGML nesting
> model, one might just be able to apply the thing recursively, with a DTD
> containing "SGML document" elements, and not need a separate Standard and
> set of definitions.   I don't consider that particularly harmful,
incidentally: 
> for what SGML is designed for, clean recursion and nesting are not 
> necessarily assets, especially in comparison to what they got by not 
> having them.

Sorry.  i just don't understand this at all.  It's trivial (well,
almost) to define a us of  SGML that is easy to parse & make sense of.

>     --john

JR