Re: A28: syntax of markup declarations?

Both Tim and Charles have good points, but I side with Charles, because I
have never seen XML as an SGML-like-language, or an SGML-competitor, but as
an SGML subset. I think that we should avoid fixing all of the problems with
SGML here like the plague, except where the "problem" is complexity, or
something else that makes SGML unfit for Internet use.

But both participants confuse me with their assumption that XML needs a
markup-declaration language at all. What kinds of tools do we expect are
going to use these markup-declarations? Probably not browsers (after all,
we've bent over backwards to exempt them from needing DTDs). Probably not
search engines (for the same reason). Nor do hard-coded tools that use XML
as a syntax for passing well-defined objects back in forth.

So who? Probably structured editors and document validators. But these
editors and validators ALREADY EXIST and they are validating SGML editors
and parsers. So do we really expect a new set of XML validating editors/ to
come into existance that support the XML declaration language, but not the
SGML declaration language?

From my knowledge of the "internals" of validating editors, parsing the DTD
and declarations is just a small part of the problem. Maintaining an
interactive, intuitive user interface to a document WHILE you are editing is
the hard part. In other words, solving the problem of "import" is easy. It's
"maintainance" and "UI" that's a hassle. So I do not think we are going to
see a flurry of new XML editors if we simplify the parsing and markup
declaration syntax: that's not what's keeping people out of the market.

As evidence I will site the fact that there are no tag-level validating HTML
editors (a la HoTMetaL and Spider) that are not based on full SGML parsers.
All other HTML editors are either non-validating, or are massively "WYSIWYG"
so that users do not work with tags at all. AFAIK, nobody has implemented a
validating HTML structural editor from scratch.

I am similarly not convinced that there is a dirth of high-quality
validating parsers. Is the SGML DTD syntax really so difficult to read that
it is the "bottleneck" in implementing these things? I suspect that is the
SGML instance syntax that is the problem.

In other words, I don't think that there is ANY problem with the current
situation w.r.t validating parsers and editors, and I don't think XML should
try to fix it. 
If XML simply does not address the issue of structural validity,

 * those that care about structural validity will use XML as an SGML subset,
and buy stripped-down XML as SGML tools,

 * those that don't care will have a smaller, simpler specification, and
will use cheap tools that do not do structural validation,

 * those that want to use a completely different technology for validating,
such as Java, Java Script, Scheme or DSSSL can use that.

<PHILOSOPHY>*
Maybe the time has come to investigate "DTD alternatives" and maybe the Web
community is just the diverse user base that should do that. My experience
with SGML editors suggests that parsing the DTD is only the FIRST STEP in
making a usable structural editing environment, so maybe we need more
powerful editing-rules definition languages. 

Similarly, a DTD is only the first step in determining if a document
conforms to a particular SGML application, so maybe we need more powerful
document-application description languages. If we give the Web community
some lattitude to experiment, they/we may come up with some neat things. 

If so (or if not) we can always standardize a markup declaration syntax in
XML 2.0 (a new version), or in XML-validation-language (an add-on), or, best
of all, in SGML97. If there is TRULY a market for a non-SGML markup
declaration language, then the market will become apparent between the
launch of XML and the first revision. We will have had lots of time to think
it through, and can decide carefully where to exceed SGML's limitations, and
where to use a subset.

If the market interest does not materialize, then we will have saved
ourselves some effort now (which could translate into a better spec in other
areas), and simplified the spec by a few pages.
</PHILOSOPHY>

 Paul Prescod

<!-- Interpretation note: RE's preceding and following tags are meant to be
insignificant, and are only included for readability =) -->

Received on Monday, 7 October 1996 15:48:37 UTC