🚀 go-pugleaf

In the discussion of FrameBuilder, the phrase "full SGML support"
has been bandied about.  The problem with the term is that anyone
who claims it currently is lying, if we take it literally, because
no-one supports the LINK feature (that I know of) and no-one supports
CONCUR, that I know of, thus, no-one provides "full" SGML support, and
if anyone claims to support those, I'd want to see proof of how they
do it before I accepted their word for it.  I would not accept parsing
of valid LPDs with no other LINK-related function available as "support",
for example.

I wonder if we shouldn't agree as a community what "full SGML
support" really means so that we have a consistent and reasonable
standard for applications, a standard that is not onerous but that
is complete enough to be useful and worth advertising.

I would accept the following definition of "full" as reasonable:

o Support for all *required* features of SGML
o Support for variant syntaxes and any set of capacity values
o Support for SUBDOC

I would like to see support for the following as part of "full",
but wouldn't push the matter:

o Support for the APPINFO statement in SGML declarations (minimally,
  making the information defined on APPINFO available through one
  or more application interfaces).
o Support for LINK.

I would not insist on CONCUR, despite Michael Sperberg-McQueen's arguments
to the contrary.

Perhaps we can define "complete SGML support" to mean support for
*all* aspects of ISO 8879.  This would prevent pedants like Erik
and myself from getting difficult when people claim "full" SGML
support and give us, the community of SGML users, a somewhat
reliable method of judging applications using a reasonable set
of criteria.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709