quantity sets and capacity sets

Martin Bryan writes:
>- HTML has extended the Quantities defined in the reference concrete
>syntax:  should XML offer less flexibility than HTML?

I don't know in what way HTML has extended the quantities; can you
expand a bit?  Nor am I clear what you mean by offering flexibility
here.  Is eliminating quantity limits entirely, or fixing them all at
very high values, flexible?  Or to be flexible must we allow users to
prescribe name lengths of 6 and litlen of 20?

As far as I can tell from reading them, virtually all of the proposals
for simplifications or subsets of SGML propose doing one of two things
with capacities and quantities:  ignoring them, or doing away with them
entirely.  I have yet to encounter an implementer who said the limits of
their implementation were well described -- or described at all! -- by
the capacity set; some have said one might use the quantity set to do
things like set buffer sizes for memory allocation, but I haven't yet
met anyone who said they actually did so.

I take the basic idea of the capacity set to be a simple and good one:
allow an application to recognize at once, if it cannot handle a
document because it is too large, so that the application may fail
quickly and gracefully rather than slowly and painfully.  I like the
idea in theory.  It does not seem to me to have proven itself in
practice.  At least one implementor has told me that all of the code
in his parser for checking quantities and capacities was added on after
the fact, purely for conformance reasons, and served no purpose in
allowing early recognition of memory shortages or other resource
problems.

Some people might say that a standard which claims it makes no
assumptions about implementation strategies ought perhaps to avoid
trying to specify things like buffer sizes.

>- the SGML community has already agreed on a new set of Quantity
>defaults for the next version of SGML: should XML offer less
>flexibitity than the next version of SGML

This sounds interesting; can you point us to documentation for this new
quantity set?  This is the first I remember hearing about it.

If restricting flexibility allows XML to be more easily implemented,
and thus more widely implemented and cheaply supported, than all of
8879, then yes, I'm in favor of XML being inflexible, simple, and cheap,
rather than flexible, baroque, and exorbitantly expensive.  Where
restricting flexibility doesn't help keep the implementation simple,
I don't see much point in it.

-C. M. Sperberg-McQueen
 ACH / ACL / ALLC Text Encoding Initiative
 University of Illinois at Chicago
 tei@uic.edu

&disclaimer;

Received on Monday, 9 September 1996 17:14:10 UTC