Re: Deploying new versions [Was: Versioning HTML at the server]

Daniel W. Connolly (
Fri, 28 Oct 94 18:01:19 EDT

In message <199410282132.OAA11203@rock>, Terry Allen writes:
>Larry writes:
>HTTP client/servers should be enhanced to allow version and level
>attributes in its 'accept' and content-type attributions, e.g.,
> text/html; level=3, version=2.0

First of all, this is easy to say, but it's in fact impossible to
do. You _cannot_ change all the HTTP clients and servers in the world.
You can only devise strategies to deal with their behaviour, and
design _future_ clients, servers, and versions of the protocol to
interoperate with the installed base reliably.

The fact of the matter is that 'text/html; level=3; version=2.0' might
as well be 'application/sniff-o-matic' to todays browsers. The CERN
libwww code compares content types using plain old strcmp().

>may (or may not) be equivalent to:
> text/sgml; dtd="-//IETF//DTD HTML Level 3//EN//3.0"

>I should think it must be equivalent, and as a detail that
>the name of the attribute should be FPI (Formal Public

The business of text/sgml; fpi=... is a pretty hairy ball of wax
that I'd rather not get into right now. (Though the emergence of
the SGML Open entity catalog may simplify some things...).

But in general, yes: the combination of level and version
maps to a formal public identifier and hence the corresponding

> Of course there's the complication of those
>Recommended and Deprecated sections. Dan?

Those are really an authoring concern. I don't think they complicate
the format negociation stuff, unless somebody wants to write a browser
that only handles recommended idioms.

Their utility is that an author can build documents and check that
their structure is maximally available to an SGML parser. For example,
in 'recommended' or 'strict' mode, the SGML parser can validate that
anchor names are distinct. If they're using SGML-based tools to print
their documents, and they tell those printing documents to apply a
certain style to all P elements, it's handy to validate that there is
no stray text laying around outside of P elements.

So these recommended/deprecated distinctions are useful, but not