> At 06:06 pm 12/22/95 -0500, Arjun Ray wrote:
> >On Fri, 22 Dec 1995, Eric S. Raymond wrote:
> >> Doesn't address the underlying problem, which is the coincidental cohesion of
> >> an abstraction (scrollable display extent) with a representation (file).
>
> > [...] the operative concept is "document entity", i.e. everything
> >between <HTML> and </HTML>[*]. The "abstraction" is merely a roundabout way
> >of saying that rendering the document entity on certain devices could
> >require a scrolling (or paging) capability in these devices: but the
> >document entity *itself* carries no such assumption.
>
> I don't see where it addresses the problem that Eric posed--that
> being the attachment of HTML to the "scrollable display" abstraction.
I don't see the problem, because I don't see the attachment:-)
I remember early drafts of the HTML 1.0 spec, where the phrase "pageless
model" was used: in that (trivial) sense one could say that the entirety
of a HTML document is one "page". And strictly speaking, "scrollable
display" is hardly an abstraction: it's a rather concrete artifact of a
particular rendering context -- involving a "screen" being smaller than
the "page" -- to which HTML is *not* tied.
> The current implementation, even though it's supposedly based on a
> documentation language (SGML), has no support for non-scrollable page
> definition.
There seems to be an implicit imputation of "one screenful" -- or some
such scrolling constraint -- to a natural, more likely convivial,
definition of a "page", with which the "pageless model" being at odds has
all at once become a "problem", only by an inversion of the conceptual
model. The design of HTML is such that "multiple pages" are most naturally
expressed as multiple entities.
> What he's suggesting, and I agree, is that we disengage the
> "coincidental" tie between the representation (HTML) and the abstraction
> (scrollable displays) by carefuly and minimally extending the language
> to support a more general abstraction (paper).
Since I'm clearly not understanding this "scrollable display" business,
why paper is a more general abstraction escapes me entirely.
> This would extend the usefulness of HTML to include applications
> where a document needs to be available in both srollable (WWW) and
> non-scrollable (paper) versions with one source file (HTML) without the
> author having to mainatain multiple source versions of the same document.
Though the terms used have been different, all I've gathered so far is an
argument that converting from a pageless model to a paged model somehow
eases maintenance. But then, what's the *real* problem? If it's a question
of having a single master source from which to produce target-specific or
customized versions, some *other* SGML application could be the way to go.
Roll your own DTD, and either use a revision control system with make, or
generate output on the fly.
I question the idea that *HTML* has to be the "one-stop shopping" answer.
Regards,
Arjun