Subject: Reply: Simplification & disambiguation revisited

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.