On Wed, 6 Oct 1999, Rick Jelliffe wrote:

Well, my argument on this particular point is based on 15.2.1 and 15.2.2 of ISO 8879. The "shall not prohibit any markup that this International Standard would allow in such documents" is of course subject to the specifics of an SGML declaration for what in fact is "allowed" to begin with, and we now have a lot more wiggle room. Now, K.3.9 says

: The public identifiers identify additional requirements for the : document, including requirements unrelated to the SGML language. These : requirements are in addition to, and must not contradict, the : requirements of this International Standard.

which suggests no new interpretation of 15.2.2. And none of the examples in Note 22 suggest that markup constructs are also in play (which is basically what 15.2.2 is about.)

But, yes, Annex L does mention restrictions on "SGML language constructs" for XML. (Stuff like data attributes and &-models, I suppose)

Unfortunately, both reasons for wanting this - the overt one ("we need a version indicator, so we nominate the DTD FPI for this") and the tacit one ("Keeping The Web Safe For Netploder, since it'll barf on anything else") - are bogus. Versioning is still a *real* problem, and the plight of Netploder is no excuse for establishment via a formalistic fig-leaf.

Perhaps a clarification with respect to 15.2.2? Other than that, how about a detailed write-up of the SEEALSO parameter (i.e. motivations, scenarios, substantive intent, etc.)? Actually something of this sort for all the new WebSGML stuff would be a welcome addition to Wayne Wohler's classic tutorial.

As a design document (e.g. DTD(s) plus documentation for an enabling architecture), yes. As a "standard" aimed at real-world practice, defined as stupefied awe of hysterically hyped wowsers, no.

Another way to draw a distinction is to say that East is "HTML, the SGML application" and West is "text/html, the bits on the wire", and never the twain shall meet. An SGML application with a raft of scraped and scrounged "Added Requirements" is not the way to describe, much less rationalize Web practice.

Like it or not, KTWSFN is an integral part of W3C activity. I don't think I have to remind you of smug officious sanitized euphemisms like "Level 3 browsers";)

It's time to call a spade a spade.

Arjun