Re: A28: syntax of markup declarations?

> At 06:20 PM 10/7/96 -0400, Steven R. Newcomb wrote:

> I think I've said my piece on the main issues here.  But there is
> one Steve Newcomb's statements that I *must* challenge:

> >  As information management professionals, I
> >can't see any way we can recommend XML to our clients unless their
> >information assets -- and our clients themselves -- are already in the
> >realm of SGML:

> If this is true, we're wasting our time.  The main benefit of XML is
> that it might well expand - immensely - the number of people who are
> using descriptive markup and standardized formats, instead of
> presentational/mongrel markup and proprietary formats.  I personally
> plan to recommend XML, vociferously, to the Web publishing
> population, when they hit the HTML brick wall, and the document
> management profession, when they get tired of dealing with documents
> that are opaque proprietary bit blobs.

> XML is the easy on-ramp to SGML.
> 
> If we go on preaching to the existing SGML choir, why bother doing this?

Tim, I've read your remark 4 times, and I must admit I don't
understand why you think it challenges or contradicts my concerns.  I
can only assume I did not make myself clear.  I agree wholeheartedly
with everything you say above, _provided_ that XML's syntax is
definable as a proper subset of SGML's syntax.  That's what I meant by
"already in the realm of SGML."  XML can't be "the easy on-ramp to
SGML" if the ramp can't take you to SGML.

I'm going to hazard a guess as to what you were thinking when you
wrote the above.  If you're saying that the use of <!ELEMENT and
<!ATTLIST declarations are harder to learn to use than equivalent
specialized document instance constructs, I'd like to know why you
think that.  As Charles pointed out, the semantics are just as complex
either way, so that can't be the issue.  To me it's intuitive that
meta-information is easier to recognize when it is recognizably
different from information.  This principle is basic to SGML and XML
already in that markup is readily distinguished from data.  At another
level, markup declarations (the meta-information of instances) should
be recognizably different from markup-and-data.  I see plenty of
reason to maintain the recognizability of that distinction, which is
already present in SGML and is well-established, no good-enough reason
to abandon that recognizability, and no convincing evidence that the
alternative being proposed is any easier for anybody, in any context,
or in any way.  To me, in fact, it looks harder to teach and harder to
use, precisely because a vital distinction between levels of
abstraction is (deliberately but misguidedly) obscured.

[Jon Bosak:]
> 1. It makes no sense to claim that we have created a syntax suitable
> for the markup of structured data in general and then not use it for
> the markup of the structured document that defines a particular
> schema.  From a marketing standpoint this is indefensible; from a
> logical standpoint it is absurd.  I have heard no one deny this.

Precisely to the contrary, I maintain for the reasons given above that
it is good marketing to distinguish the steering wheel and other user
interface doodads from the rest of the automobile and it is
indefensible to do otherwise.  I also fail to understand why, from a
logical standpoint (whatever that means), it is absurd either.  To me
it makes plain good sense.  Most people want to be able to tell the
difference, at a single glance, between the spare tire and the
steering wheel, even though there is no theoretical reason why cars
can't run on four steering wheels, or why the driver can't mount the
spare tire on the steering column and use it for a steering wheel.

For the record, please let me add that this is familiar territory to
me.  The GCA CApH activity, which I chair, created a DTD for SGML
DTDs.  The work on that project was mainly done by Wayne Wohler.  I
learned during that time that there have been several projects to
accomplish the same goal, which is to provide the ability to use the
same information management tools and techniques on DTDs that can be
used on SGML documents.  It's a worthy goal, and I don't regret the
exercise.  I can imagine situations in which it would be appropriate,
but it's no longer fundamentally interesting because there's now a
better way to accomplish the same goal.  The new way is to regard the
DTD information (just as formally, if not more so) as the values of
properties of components of document instances (see Clause 9 of DSSSL
-- the SGML Property Set).  This maintains the meta-ness of DTD
constructs, keeping them in the context in which they have their
intended effect, and it does not unnecessarily and confusingly elevate
DTDs to the status of documents in themselves.


Best regards,

--Steve

***************************************************************
*          Steven R. Newcomb | President                      *
*     direct +1 716 389 0964 | TechnoTeacher, Inc.            *
*       main +1 716 389 0961 | (courier: 3800 Monroe Avenue,  *
*        fax +1 716 389 0960 |  Pittsford, NY 14534-1330 USA) *
*   Internet: srn@techno.com | P.O. Box 23795                 *
*        FTP: ftp.techno.com | Rochester, New York 14692-3795 *
* WWW: http://www.techno.com | USA                            *
***************************************************************

Received on Monday, 7 October 1996 23:13:37 UTC