[Please note that I've received no mail since last Thursday evening, since
our sysadmin failed to restart the sendmail daemon after a reboot. Duh. I
wasn't being rude if anyone didn't get a reply...]
Dave Morris <[log in to unmask]> writes:
>Glenn, thanks for taking the time to describe (again) the SGML marked
>section concept. Knowing now we are talking about the same 'thing', see
>my comments below.
>On Thu, 28 Dec 1995, Glenn Adams wrote:
>> The UA would have to support a set of predefined parameter entities
>> which indicate its support for various tag sets such as:
>This is the crux of my objection ... all parameter entities must be
>pre-defined and therefore my argument for this as a general mechanism
>for handling backward compatibility fails. The SGML marked section
>definition fails to allow for ELSE or NOT such that one can catch
>the unknown or don't care cases. If it were possible to get early
>agreement in some form from the groups working on revising SGML to add
>this capability then I agree we have a solution with awkward but
>tolerable syntax. Then the HTML group could simply work to define a
>extensible naming scheme for features to avoid collisions AND to
>integrate the scheme into content negotiation so that a server could
>opt to perform the marked section processing if so desired.
>> Such a proposal would be fully consistent with general SGML practices
>> and have the most likelihood of widespread implementation by UA vendors.
>My major concern in the end is 'widespread implementation by vendors of
>_popular_or_commonly_available UAs'. For that I'm not sure I accept your
>conclusion. What counts is convincing the flagship vendors that this is
>the best approach.
There seems to be some confusion in this thread between server-side content
negotiation and UA-managed display of procedural markup. I won't attempt to
resolve this, but would like to add that backwards compatibility would
still rely on a multiplicity of document types whose managed delivery was
based on the HTTP User-Agent field rather than any HTML procedural syntax.
That is, assuming the current crop of browsers will be in operation
indefinitely, any use of procedural markup (such as <IF>, <ELSE>, <ELSE-IF>
and </IF>) would be ignored in current browsers, resulting in a broken
behaviour. Given that assumption, any proposed addition of procedural
markup becomes another negotiated HTML feature/extension, and HTTP content
negotiation is needed anyway.
And if content negotiation features are required, I don't quite understand
any other need for an if-then-else feature in the HTML language syntax
itself that SGML marked sections wouldn't handle. Marked sections
specifying feature sets already exists within the HTML 2.0 DTD, and
expanding upon this feature to handle extension features is a demonstrably
easier method than relying on procedural markup within individual
documents. I'll try to outline this below.
Marked sections might be used within the DTD itself as feature "switches"
(limited to the keywords INCLUDE and IGNORE, as per Glenn's suggestion),
with some standardized parameter entity naming scheme linking specific
feature sets to FPIs. For example, if "W3C-Raggett-tables-x04" happened to
be the registered entity name for Dave Raggett's tables draft, we merely
define "W3C-Raggett-tables-x04" (never mind the naming specifics for now)
as either "INCLUDE" or "IGNORE" and allow a marked section to switch it in
or out of the DTD.
I've been reading through SGML Open's TR9401  on use of SGML catalog
files, and I think most of the soup of language features are now available,
just waiting for someone to put them all together. An FPI naming scheme is
also outlined in the DocBook DTD maintenance documentation, and outlines a
managed naming of FPIs based on subsets or extensions to the language. We
then have a linkage between the (registered!) parameter entity names within
the DTD and the marked sections within the document instance. For example,
register the FPI itself along with the parameter name, as in
PUBLIC "-//IETF//ELEMENTS HTML V2.0-Based Extension Tables-V0.4//EN"
and allow content negotiation of marked sections to occur using any
combination of marked sections and catalog files. I can think of several
implementation schemes just off the top of my head.
You would then use the User Agent field coupled with a parser that
recognizes marked sections, in order to correctly deliver only those
document sections that are appropriate to the UA.
You state your primary objection to marked sections as being based on the
current lack of pre-defined parameter entity names. As extensions are added
to HTML, there will need to be some method of differentiating which
features are turned on and off. Dan begins this in the 2.0 spec with
"HTML.Forms" as a feature test entity.
Collisions in the naming scheme won't be a problem if we opt for IANA
registration of extension names. This was suggested as early as
September, and while the details have yet to be worked out, content
negotiation via registered extension names could be a viable
extension-switching method, with the parameter entity names either a direct
relation to the registered name (such as described above), or an additional
Larry Masinter is working up a content negotiation working group, which I
think will address some of these issues. In a recent message, Ron Daniel
asked for volunteers on writing a proposal to create a DNS-like system for
mapping FPIs to URLs/URNs. James K. Tauber <[log in to unmask]> has
created a listserve for this discussion as well.
I hope this was more helpful than confusing...
 "Entity Management: SGML Open Technical Resolution 9401:1995
(Amendment 1 to TR 9401)",
Paul Grosso, Chief Technical Officer SGML Open (1995 September 8)
 "DocBook V2.3 Maintainer's Guide /
New for DocBook V2.3 (September 1995)"
Eve Maler, ArborText, Inc.
 "Proposal: HTML Extensions Registry (Was: HTML extension version numbers)"
Murray Altheim, National Technology Transfer Center
Murray M. Altheim, Information Systems Analyst
National Technology Transfer Center, Wheeling, West Virginia
email: [log in to unmask]