Organization: Naggum Software; +47 2295 0313
Newsgroups: comp.text.sgml
Reference: Arjan Loeffen
CTS archive link: here
[Arjan Loeffen]
| In this submission I've extended these rules. As I'm bound to close
| this section of my PhD thesis, I feel I should show them to you first,
| asking for comments and/or corrections. If you have better names for
| the simplification rules, let me know. I've heard of no other attempts
| to augment the list of Rath; if you have such a reference, please let
| me know.
many thanks to Arjan for making the effort to codify these rules, of which
I'm sure many of us have had an intuitive understanding. the rules seem to
be correct as far as I can tell.
now that the body of work on ambiguity has grown to a point where there is
no doubt that SGML's concept of ambiguity is overly restrictive, we need to
put some of these rules into the standard, lift the silly ambiguity rule
and allow content models that can be reduced or rewritten to unambiguous
content models (as currently understood) before the parser checks against
the contents. since this rewriting is simple but tedious, and produces
counter-intuitive and unreadable results, there is no point in having human
users be forced to understand the complexity of these rewriting rules and
their effect upon content models. there is no point in having a standard
that is artificially restricted to the trivially implementable when the
body of knowledge on this area has so clearly and unambiguously shown that
the restriction is also meaningless.
to revoke the entire ambiguity nonsense in SGML would not change one iota
of the meaning of any existing, valid SGML document, and can be implemented
at any time by a reasonably competent programmer. it is my understanding
that several vendors already offer mechanized help in disambiguating the
more complex content models that fall natural to a human user, yet are
mysteriously disallowed by their parser.
the standards committee is not going to revoke this rule unless a large
number of you write to ISO to demand that it be revoked. it is important
that you make yourself heard before your suggestions will be met with a
rejection slip reading "it is too late to accept this for this revision of
the standard -- your suggestion has been entered in the database for the
possible revision of SGML in 2006." this database is a black hole -- not
even members of the committee have access to it or know what's in there.
this is not how international standards should be made. bring this to the
attention of your national standards body, especially if you're not in the
United States.
also beware that ANSI can rush their standards through ISO on the fast-
track schedule. this is what happened to that ISO 12083 disaster. if you
want SGML to survive into the next millenium, you need to act, and act now.
you will not be notified before it's too late. above all, make sure that
you do not vote to reaffirm the 1986 standard without revising it when it
comes up for review in 1996. make your views heard _now_, and you will
have a much higher chance of being heard. ISO has already requested
national bodies to start the internal review process for standards to be
formally reviewed in 1996. if you don't know how, send me mail, and I will
make sure you will be heard by giving you a name in your own national
standards body.
#<Erik>
--
The check is in the mail. This won't hurt. You'll find it on the Web.
Back To Complete Subject Listing on remote site.
Archive last updated dd. 02/04/96
Suggestions to the compiler.