ietf-822
[Top] [All Lists]

Re: Richmail & Idraw

1991-06-13 17:39:34
Date: Thu, 13 Jun 1991 13:31:24 -0400 (EDT)
From: John C Klensin <KLENSIN(_at_)infoods(_dot_)mit(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>