Re: A28: syntax of markup declarations? (LONG)

On Mon, 7 Oct 1996 13:27:51 -0700, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak)
wrote:

>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.

On the contrary, it is both defensible and surd.

There are strong differences of opinion on the suitability of SGML for
representing  things other than documents. There is a thread on c.t.s regarding
a DTD for personal identity which has evolved into a general discussion of the
use of SGML for data modeling and other non-document things. (N.B.: A document
*type* is very different from a document.) There has been no mention of XML or
DSDs on c.t.s, so I'm sure you'll be amused, even if not (as you should be)
chagrined at Piercarlo Grandi's posting, which I've excerpted here. In
attempting to show the absurdity and indefensibility of using SGML to model
things other than document instances, he trots out the worst example he can
find: using SGML instance language to define document types. It even looks like
a DSD:

>On Mon, 14 Oct 1996 14:38:16 +0100, piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

>>I'll spare myself the DTDs, but consider two instances/examples of two
>>hypothetical SGML architectural forms; the first is called MarkDown:
>>
>>  <ELEMENT TAG=html>
>>
>>    <ELEMENT TAG=head>
>>      <ELEMENT TAG=title TEXT="A sample MarkDown document"></>
>>    </ELEMENT>
>>
>>    <ELEMENT TAG=body ATTRS="bgcolor" ATTVALS="#ffffff">
>>      <ELEMENT TAG=h1 ATTRS="center" ATTVALS="yes" TEXT="What is MarkDown?"></>
>>      <ELEMENT TAG=p>
>>	MarkDown is a caricature of SGML; it is an imaginary
>>	architectural form whose semantics are document markup, where
>>	the <ELEMENT TAG=code TEXT="tag"></> attribute is the one to
>>	which the MarkDown semantics are attached.
>>      </>
>>    </>
>>
>>  </>
>>
>>Now this is a monstrosity, but I hope the analogy is clear, even if a
>>bit forced in some respects. A bit less forced is the following example
>>for the architectural form PasCool:
>>
>>  <FUNCTION ID=euclid>
>>      <PARM ID=x TYPE=int><PARM ID=y TYPE=int><RESULT TYPE=int>
>>  <!-- or perhaps
>>    FUNCTION ID=euclid PARMS="x y" PARTYPES="integer integer"
>>    RESTYPE=int
>>  -->
>>    <BEGIN>
>>      <WHILE NEQ="x y">
>>	<IF GT="x y">
>>	  <THEN><SET VAR=x><MINUS OPS="x y"></MINUS></SET></THEN>
>>	  <ELSE><SET VAR=y><MINUS OPS="y x"></MINUS></SET></ELSE>
>>	</FI>
>>      </WHILE>
>>      <RETURN VALUE=x>
>>    </BEGIN>
>>  </FUNCTION>
>>
>>  <CALL PROC=writeln><APPLY FUNC=euclid ARGS="9 6"></APPLY></CALL>
>>
>>This is a mostrosity too: note that this is, like so many HyTime
>>examples/actual uses, including your "enrolled" one, pure markup without
>>any contents, which seems a bit odd.

[Jon also wrote]
>3. Unlike many other features -- marked sections, for example -- that
>we can defer for the moment if we wish and introduce in a later
>version of XML, this is not something that can wait.  We have to take
>this approach from the beginning or it will never happen.

That's not true, since document instances aren't affected and most (all?) XML
documents won't even be transmitted with DTDs intact.

XML can start with core SGML for its DTDs, since the primary focus of XML will
be on DTDless instances. If there is a real demand for an alternative DTD
syntax, we can add DSDs to SGML97 and then offer them in XML2 as conforming to
8879.

What really is indefensible and absurd is to risk the growing and successful
market we have on an unproven alternative whose merits are highly controversial.
--
Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553
           13075 Paramount Drive * Saratoga CA 95070 * USA
  International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime
 Prentice-Hall Series Editor * CFG Series on Open Information Management
--

Received on Monday, 14 October 1996 18:42:06 UTC