Re: A28: syntax of markup declarations?

>A.28 Should XML use the markup-declaration syntax described by ISO 8879
>clauses 10-11, or should XML define a specialized document type and let
>its markup declarations use the document-instance syntax, as proposed
>by MGML?
>

Breaking my general inclination to keep quiet in this discussion, I weigh in
on the side of those who believe the the XML declaration syntax, if there is
to be such, should be derived from the SGML syntax.

I've spent the past 15 years watching people try to improve on SGML syntax.
I've occasionally joined the effort. I still hold that there are some things
we could leave out and most users wouldn't miss them. But in spite of the
fact that someone might be able to come up with a more "computer sciencely"
way of doing what SGML does, we still have a sizeable base of (1) people who
actually know how to use the beast and (2) tools that have been written in
support of that effort. I just can't see dumping that to prove a point,
whether that there's a more elegant way or a way to do it in instance syntax
or whatever. 

I keep coming back to the nature of SGML: it's a metalanguage. The things we
loosely call "SGML documents", our instances, aren't what I'd call roperly
SGML documents. They're documents in languages we've created using SGML to
define grammars. SGML isn't by any means perfect, easy, etc., but it is at
least a workable language for defining the grammars of instances. To go over
to instance grammars and then try to use them to define subinstance grammars
is a case of using inappropriate tools. I just can't buy that.

I second Steve Newcomb's assertion that trying to devise a new metalanguage
-- because that's what it would be -- would hurt it, HTML, SGML, and all of
us. There are enough SGML users out there for us to make a living supporting
them. But there aren't enough of us to support a lot of "standards"
projects, and we're already in danger of spreading ourselves too thin. Let's
concentrate on making a reasonable, usable, selection of things to adopt
from SGML, then, if we find we really have to change something, let's do it
in a way that can feed back into SGML 97.

Jim

Dr. James D. Mason
(ISO/IEC JTC1/SC18/WG8 Convenor)
Lockheed Martin Energy Systems
Information Management Services
SGML Systems Development
1060 Commerce Park, M.S. 6480
Oak Ridge, TN  37831-6480   U.S.A.
Telephone: +1 423 574-6973
Facsimile:  +1 423 574-0004
Network: masonjd@ornl.gov

Received on Tuesday, 8 October 1996 14:15:47 UTC