Re: RE dtd2.html

Dave_Raggett <dsr@hplb.hpl.hp.com>
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9305270930.AA15764@manuel.hpl.hp.com>
Subject: Re: RE dtd2.html
To: terry@ora.com
Date: Thu, 27 May 93 10:30:45 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Terry,

Thank you for your comments on "DTD2.html". I am still at an early stage in 
developing this, and am very appreciative of input at this stage.

> + FLYLEAF seems misnamed to me.  As its contents are adequately
>        contained within FRONT, you can just let this 
>        info float withing FRONT.  Then the title page can be
>        assembled from the FRONT info.

When you browse through a bookstore, you work through a kind of hierarchy:

    a)  the generic classification of this
        part of the store e.g. SF, or Languages

    b)  the information on the spine of the books

    c)  the cover page - title, subtitle, illustration, ...

    d)  On opening a book the flyleaf often contains a
        useful summary of what the book is about

    e)  You may next look at the contents before
        browsing rapidly through the book itself.

It seemed a promising idea to try and support this kind of behaviour
for on-line media. For instance you could see reduced pictures of
the covers of several books at once. This hierarchy would also
serve in searchable catalogs of available material.

The idea of the FLYLEAF tag was to provide markup that captures
part of this hierarchy.

> + AUTHOR and EDITOR may occur more than once.

Thanks.

>  + LEGAL, like FLYLEAF, probably isn't needed.

You may be right here - I note that the ISBN number appears in a
variety of places in printed matter.

>  + Are you contemplating nestable SECTIONs?

Yes.

> + I am not sure that STRONG, B, I, and U are desirable as
>    elements.  These formatting characteristics ought to
>    get applied to elements on the basis of their meaning.
>    But that's a rather SGML point of view; you may wish
>    to allow this slop room for WWW.

I don't like them either. They are present in HTML to support
importing (scanned) documents for which a filter has no way of deciding
the original meaning.

> + PRE is not really a paragraph type, as the contents of
>    such sections need not be paras.

My mistake. The <P> tag isn't allowed in the PRE element anyway.

> + MENU seems to be simply a subset of UL, and could be eliminated.

It crept into HTML at an early stage and I would prefer <UL COMPACT>
but will have to keep MENU for backwards compatibility.

> + IMG needs some TYPE attribute.

The type is usually defined by the referenced data, preferably as a MIME
type or failing that on the basis of the file suffix or the presence of a
well known pattern at the start of the data.

> On the whole this is a compact DTD and looks workable (though only
> real testing can prove that).  How is it related to HMML?

Thanks!

HMML is the name of an internal and experimental DTD developed by
Pei Wei. However, things became confused when Tim Berners Lee started
using "HMML" for the proposed replacement for the original HTML DTD.
To avoid confusion I am calling the new DTD "HTML+" which also emphasises
that it is a superset of the current format.

Can you help me with a simple SGML problem? I have searched through
Goldfarb's handbook, but can't find how to specify attributes which
don't need values, as in <DL COMPACT>. Do you have any ideas?

Many thanks,

Dave Raggett

p.s. Thanks for your earlier comments on tables. I am now thinking
    about extending definition lists to support tables with optional
    title, and column headers, and limited adjustment/width info
    for efficient rendering.