Re: Dropping the Normative Reference to SGML (was: I-D ACTION..)

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.)

Rick Jelliffe
Academia Sinica

Received on Wednesday, 6 October 1999 10:37:20 UTC