From: erik@naggum.no (Erik Naggum)
Newsgroups: comp.text.sgml
Subject: Re: PSGML -- The qwertz dtd
Date: 13 Apr 92 15:53:09 GMT
	<1992Apr9.062951.27399@cco.caltech.edu>
Reply-To: Erik Naggum <enag@ifi.uio.no>
Organization: Naggum Software, Oslo, Norway
Originator: enag@gyda.ifi.uio.no

Mark,

When I was taking philosophy many years ago, we learned about the
difference between the metaphysically (naturally) _given_ and the
_man-made_, the major point being that the _given_ is just that, and
it could not have been otherwise, while the _man-made_ not only could
have been otherwise, but it can be good or bad because a will was
behind it.  This difference is crucial in philosophy, because you run
astray in all sorts of problems if you get them confused.

In your articles, you have given me the impression that you see the
document and the DTD you're dealing with as given, and SGML as
man-made in just the sense defined above.  In other words, you wish to
change (or complain about) SGML because that's the only thing you
think you can change.  You've run into exactly the kind of confusion I
learned about in an introductory philosophy class a decade ago.

For the sake of argument, I would like you to consider the opposite
assumption: that SGML is given, that your DTD could have been
otherwise, and can be changed, and that the document can be edited
with an editor.

You have implicitly addressed a number of issues without making them
explicit (despite my sincere request to have you discuss issues rather
than examples).  Let me take care of a few of them in order.

(1) Ignore significant Record Ends (REs)

SGML has certain rules about the treatment of REs which can be
simplified and summarized as follows:

	an RE immediately after a start-tag is ignored, and
	an RE immediately before an end-tag is ignored.

That is, you already have a mechanism to ignore certain REs as part of
the language, and these REs are _insignificant_REs_.  You imply that
you wish to make more rules about the REs in the standard, and thus
dictate the semantics of REs in content.  You can't do that, since
SGML is to be treated as a given, so let's see what we can do about
it, anyway.  Nature, to be commanded, must be obeyed.

In elements where even significant REs are known to be meaningless,
you can add a short reference mapping from "&#RE;" to "".  That way,
_you_ (the user) have told the parser what you know about REs in those
elements, instead of the language forcing something about REs on you
which you might want to change in other circumstances, and then can't.

(2) Ignore leading and trailing white space

SGML has certain rules which apply to content of different types.
There is element content, in which only elements can occur, and there
is mixed content, in which both elements and data can occur.  In
element content, all white space is ignored, whereas in mixed content,
all white space is significant.

If you don't like that, you can make all leading white space go away
by making a short reference mapping from "&#RS;B" to "&#RS;".  The "B"
means "blank sequence", and consists of any sequence of SPACE and TAB
(usually).  Note that this only deletes the blank sequence without
having any effect on a possible different mapping for "&#RS;".

You can also blow away all trailing white space by making a short
reference mapping from "B&#RE;" to "&#RE;".  This way, you're certain
that you don't interfere with any mapping for "&#RE;", such as blowing
it away, too.

(3) Insert white space to enhance readability

Now that we have defined means to handle your white space problems, we
can capitalize on them to enhance the readability of the source, which
seemed so important to you.  I'd like you to take special cognizance
of the fact that we're doing this _with_ SGML, and that the problem
you previously alluded to about "an actual problem with SGML" may not
be a problem with SGML at all, but with your application and the bad
design of the qwertz DTD.

Let's try these declarations:

<!ENTITY bareRE "&#RE;">
<!ENTITY bareRS "&#RS;">
<!ENTITY % globmap '"&#RS;B" bareRS "B&#RE;" bareRE'>
<!-- %globmap can now be used in all short reference maps -->
<!-- (the qwertz DTD should've used many such entities) -->
<!ENTITY space " ">

<!shortref oneline
	%globmap
	"&#RE;" space	
	"&#RS;&#RE;" null
	"&#RS;B&#RE;" null
	...	-- rest of oneline map --
>

Your example text can now be presented like this:

<title>
		The &QWERTZ; SGML Document Types
<subtitle>
		Version 1.1 Reference Manual

and you can have as many blanks lines and as much white space you
want, on either side, without any ill effect.  This will be
interpreted as

<title>The &QWERTZ; SGML Document Types<subtitle>Version 1.1 Reference Manual</subtitle></title>

which I think is exactly what you want.  Right?


Another issue which this qwertz DTD thing implicitly brings up is
having an inclusion for the newline elements, which is empty, and then
have an entity refer to it.  Inclusions screw up the normally simple
idea about when REs are ignored and not, so a kluge is to terminate
the entity reference with an RE.  Clever, huh?  Or not, because it
causes a lot of confusion, like what we've just seen.


Mark L. Fussell <rebecca@cco.caltech.edu> writes:
|
|      *  the title was about twice as long,
|      *  you didn't want a newline in it, and
|      *  you were concerned about how it looked in the source file,
|         the stated intention of PSGML

Those who know SGML don't have these problems.  I think the problem
you have is that you think SGML is a front-end to LaTeX.  It should be
very clear that the format program, using the qwertz DTD, is designed
to be easy to interwork with LaTeX, but I would hope it has more uses
than this simplistic task.  If LaTeX doesn't care about the extra
spaces, which in my experience it doesn't, then you're complaining
about, and basing your complaints against SGML on, the intermediate
format between two tools.  Why waste your time on this?

|   but adding the last item would be cheating since I spoke of an
|   actual problem with SGML.

Please don't confuse your understanding of one application based on
very little information with SGML, the standard.  The "cheating" you
refer to is actually what people call "good design".  The qwertz DTD
should've used this, and that it does not is very bad.  As I said in a
previous note, this is mentioned in the standard itself.  I won't
demand that everybody read the standard, but implementors who haven't
should be shot.

|   In any case, having to modify an apparently reasonable DTD
|   (especially a public one) to solve somewhat unpredictable
|   "cosmetic" problems seems fairly heavy-handed.

The QWERTZ DTD is not a reasonable DTD.  But the more important point
is that it's Mark Fussell who's the least reasonable -- you want the
syntax to adapt to your whimsical wishes instead of learning its
rules, and that's in the chapter on "irrational" in my book.

|   Personally, I think SGML and the DTDs for it shouldn't really be
|   so concerned with these cosmetic issues, and wanted a way to avoid
|   the issue altogether.

SGML isn't concerned with "cosmetic issues" -- it's Mark Fussell who's
concerned with cosmetic issues.  If you had really wanted a way to
avoid the issue, you would have thought more on this, and realized
that if you were to please both Mark Fussell and Erik Naggum at the
same time, you couldn't stuff the semantics of spaces in international
standards, but instead you should provide means for users to express
their own desires in a language.  SGML has done the latter, and if you
fail to use the means available to you, why do you blame SGML?

|   Referring back to my second posting, the problems of a space after
|   the &nl (which affects whether the following newline is removed or
|   not) and of undesired spaces at the end of any line (like the
|   title line) are still left open.

What do you mean "are still left open"?  If you refuse to learn the
rules of the game, how can you expect to win?  An entity reference is
terminated by semicolon and RE, which is thereby part of the entity
reference.  The reason for treating RE in this special way is mainly
to allow short references including an RE to be converted into entity
references without producing excessively long lines.  However, an
entity name consists only of name characters, and a character which is
not a name character will both terminate the name, and be a character
in its own right.  Of course, you could complain that this is too lax,
and produces all sorts of weird results, but would you rather have
lots of errors due to missing semicolons?  This is a compromise in the
favor of the user.

I have a feeling that I'm repeating myself from previous notes, and
still not getting through.  If anybody thinks I need to clarify
things, I will, but I don't have much more to say than what I've
already said.

Regards,
</Erik>

--
Erik Naggum       |  +47-295-0313     |  ISO 8879 SGML     |  Memento,
Naggum Software   |   "fuzzface"      |  DIS 10744 HyTime  |  terrigena.
Boks 1570, Vika   | <erik@naggum.no>  |  JTC 1/SC 18/WG 8  |  Memento,
0118 OSLO, NORWAY | <enag@ifi.uio.no> |  SGML UG SIGhyper  |  vita brevis.
Newsgroups: comp.text.sgml