ISO 8879:1986 as corrected by Annex J,K,L does allow restrictions to be placed on the kinds of SGML that are permitted in a particular document type.

This uses the SEEALSO parameter of the SGML declaration, and is explained in the section on "Added Requirements". See http://www.ornl.gov/sgml/wg4/document/1960.htm Annex L is an example of such Added Requirements: it gives the additional requirements for XML.

Arjun Ray's particular point about SGML providing no mechanism for disallowing use of the internal subset is true, to the extent that a *general purpose* SGML parser must allow all kinds of markup allowed by the SGML declaration for that application.

However, it is perfectly legitimate to make a WebSGML application which does not allow internal subsets, as an added requirement. (I proposed and drafted the SEEALSO bits, but this may indeed be something that could be clarified in some future rewrite of SGML if anyone wants that.)

I agree with Arjun that HTML may not be "Conforming SGML Application", but it certainly is an "SGML Application" with specific Added Requirements. So I think it would be slack to remove normative references to SGML: they can be updated to WebSGML, since that addresses several requirements from the HTML world (no DOCTYPE required, hexadecimal NCRs, etc).

Indeed, an Added Requirements document can specify particular error-handling behaviour. So even the behaviour of near-SGML syntaxes (e.g. <font size=+1> can be specified. This remains a "reportable markup error" in SGML, of course: a good Added Requirements document would make clear that a conforming application is not required to handle any particular errors in particular ways, so such syntaxes are unsafe.

The SEEALSO parameter represents IMHO a fundamental new tack that SGML has taken (which XML cannot) in that it allows many kinds of SGML-inspired syntaxes to come into the SGML fold. The intent of SGML is to be useful to rigorously describe a large number of markup syntaxes: I don't see where it currently does not allow HTML-as-implemented to be described (except for non-nested tags which are hardly universally applauded.)

To make a SEEALSO parameter for HTML, all that is needed is for the parameter to identify the appropriate HTML recomendation. The "Added Requirements" are specified as human-readable text for implementers.

(The Added Requirements are limited: for example, I cannot change tag or delimiter recognition rules using them.)