>At 12:18 95.10.04 -0700, [log in to unmask] wrote:
>>Your poropsal to have an HTML extensions registry similar to the SMTP
>>extensions registry administered by the IANA looks quite reasonaable
>>and the IANA is prepared to act as such an HTML extensions registry.
>The HTML WG has several times expressed a strong preference that HTML be
>officially extended only by standards-track "versions", not by registered
>extensions. This is the reason why proposed individual feature extensions
>are being handled with experimental RFCs, rather than as standards-track
>ones. The responsible Applications Area Director would prefer that IANA
>start a registry of this type only in coordination with that WG, lest the
>registration mechanism become an alternative to normal IETF processing.
The HTML WG still needs to draft a method for creating HTML standards-track
versions from combinations of proposed language extensions (tables, math,
internationalization features, etc.). Absent any method, we have seen wide
implementation of nonstandard extensions, with no way of tracking/denoting
the standards or non-standards-track maturity level of those features.
There has also been a demonstrable interest in using various components of
HTML in creating alternate SGML-compliant markup languages, such as CML
(Chemical Markup Language).
As I am aware of no current mechanism that might provide these types of
functionality, I am currently drafting a proposal to modularize future HTML
DTDs (akin to DocBook 2.3's modular DTD), in order to
1. provide a mechanism for re-inclusion of the various HTML
proposals into a single draft;
2. avoid namespace collisions between core HTML DTD modules
and proposed extensions;
3. provide a reasonable method for allowing interoperability
of core HTML components with experimental (ie., not
currently standards-track) proposals while still in the
development cycle; and
4. allow core HTML components to be incorporated piecemeal
in creating alternate markup languages.
An HTML extensions registry is a requirement within a modular DTD
environment to avoid namespace collisions between component names, when
those components are not being developed by a single authorship (as is
currently the case with HTML 3.0). How language extensions are incorporated
within a particular HTML standards-track version is beyond the scope of the
proposal. However, a modular approach may provide a necessary
I have no desire or intention that an extensions naming registry become an
avenue for avoiding the proper IETF standards process -- I am a big
advocate of that process. I am hoping my proposal will encourage commercial
and independent developers to register proposed extensions _as part of the
standards process_, giving them a safe namespace within which to operate
(avoiding namespace collisions), and allowing multiple extension proposals
(inter- and intra-organizationally) to compete interoperably within the
development cycle, with only minor changes to a modular DTD driver file.
The HTML registry proposal is not contingent on approval of the modular DTD
draft, and it may be deemed desireable by HTML-WG independently for other
purposes. A modular HTML DTD and an extensions registry are linked but not
mutually dependent concepts. Content negotiation issues are entirely beyond
the scope of either.
I am still in progress in drafting both documents and will post each to the
HTML-WG as soon as complete. If you would like, I would be happy to send
you a copy of each.
Murray M. Altheim, Information Systems Analyst
National Technology Transfer Center, Wheeling, West Virginia
email: [log in to unmask]