HTML Futures (was: to <P>...)

I think that Thomas addressed two issues in his message, so here is my
response to the second.

At 04:37 PM 8/17/96 -0700, Thomas Breuel wrote:
>On the other hand, providing the full generality of
>SGML is not a solution, either, in my opinion, since having
>user-defined structures with only a syntactic framework is almost as
>useless for Web purposes as no standard at all (and that kind of
>generality was not the intent of the original SGML work anyway).

The Web does need a document architecture (probably many) but that does not
mean that all documents must use the same (or even similar) tagset.
Architectural forms are supposed to allow the full generality of SGML
without constraining a particular document to a single semantic framework.

> -- There should probably be several distinct HTML subtypes for
>    different classes of content, like memos, navigational pages,
>    product descriptions, collections of document summaries, search
>    results, etc.  Of course, the point is not to introduce deliberate
>    incompatibilities between different document types, but to provide
>    authors with frameworks and facilities for representing the
>    specific types content they have as conveniently and standard as
>    possible.

I think that "HTML subtypes" is a dead-end alley. Better to move directly to
architectural forms or "SGML subtypes". Documents on the Web will often fit
into many different categories. There must be a way of declaring their
adherence to different architectures. Either SGML archforms or DSSSL
extensions could allow this.

> -- Some HTML subtypes should provide very explicit control over
>    layout and presentation (e.g., navigational pages), while 
>    others should be primarily structural (e.g., memos, search
>    results, etc.) to allow automatic processing.

It sounds like you are just reinventing SGML.

> -- There should be standard tags supporting document indexing
>    an identifying large scale document structure (in fact,
>    this is kind of what "core-HTML" and META are trying to do).
>    Indexing information needs to be document type specific, however.

Indexing information needs to be architecture specific, but a particular
document type could correspond to multiple architectures. 
The [Proposed Convention for Embedding Metadata in HTML] shows that this is

> -- Many of the SGML conventions for "simplifying markup" should
>    be dropped and a simple, canonical syntax should be adopted
>    and enforced.

I don't buy this at all. Nobody forces authors to use these constructs. They
like them and are willing to live with the complexity. Furthermore, these
rules provide a more flexible upgrade path. Using them, we turned P from an
empty element into a container and could do the same with META or IMG.

> -- There should perhaps be mechanisms that discourage the definition
>    and use of style sheets and DTDs by individuals and encourage
>    the creation of a few common standards.  (Complexity is on such 
>    mechanism--how about DSSL? :-)

I strongly disagree. There are thousands, perhaps hundreds of thousands of
different "document types" at the semantic level (i.e. "resume", "pamphlet",
"report", etc.) Furthermore, new document types are being invented (for
instance "home page" ). Globally standardizing these document types is going
to be absolutely impossible. Even if it were possible, documents often
straddle the document types. 

Trying to shoe-horn a document into a DTD not suited to it goes against the
grain of SGML. We must have a system where there can be an infinite number
of document types and a mechanims for mapping back to semantics in
standardized architectures. Either SGML architectural forms or something
like DSSSL could allow that.

 Paul Prescod


[Proposed Convention for Embedding Metadata in HTML]

Received on Sunday, 18 August 1996 12:54:19 UTC