Re: SGML objects

Bob Stayton <>
From: Bob Stayton <>
X-Mailer: SCO System V Mail (version 3.2)
Subject: Re: SGML objects
Date: Wed, 18 Aug 93 9:29:23 PDT
Message-id: <9308180929.aa06645@scotty.sco.COM>
Source-Info:  From (or Sender) name not authenticated.
Status: RO
> From: Dave_Raggett <>
> > I don't understand how this addresses the problem
> > of delivering a large hierarchical document in HTML+
> > chunks.  
> You would break a "book" into a number of HTML+ nodes (files)
> with a "contents" node that points to the others and so on
> hierarchically as needed. Entities *wouldn't* be pulled across
> as you describe. Instead the user is free to follow embedded
> links (as now). You can also define navigational links for
> properties such as"prev/next chapter", "table of contents"
> and "glossary". These links may be defined explicitly or
> implicitly as described in the HTML+ spec. The advantage of
> implicit links is that they avoid having to insert links
> into all the constituent nodes and further allow given nodes
> to occur in more than one "book".
I agree that the current HTML and HTML+ are suitable for
breaking up a book into nodes as you describe, and we are
planning to do it that way. But HTML and HTML+ as currently
proposed have a flat, not nested, section structure. That
makes it is easy to break up the long stream into parsable
pieces for a modular file structure.

However, several people have suggested making sections
into containers that nest, as with the DocBook and
other DTDs. My question was: if that happens, how
would large books be broken up into modular files?
Having not received a good answer, I will argue to
keep the current flat DTD structure as you have
proposed in HTML+.