From: sandoval_perry@allin1.adpdp2.lanl.gov (108101)
Subject: Re: Parting PSGML
News-Software: VAX/VMS VNEWS 1.41    
Organization: Los Alamos National Laboratory, EMVAX
Date: Thu, 16 Apr 1992 01:25:00 GMT

In article <1992Apr15.121457.2716@cco.caltech.edu>, 
            rebecca@cco.caltech.edu 
            (Mark L. Fussell) writes...
> 
>Howdy all,
> 
>This will be my last comment to this news group on this issue, since I am  
>losing an argument by nobody seriously considering what I have to say or the  
>examples I give -- at least for the posted responses.  Eric's and James's  
>comments were welcome and helpful (although the overall tone wasn't so good).   
>I have read, tested, and pondered over everything posted or mailed to me,  
>contrary to others' implications or statements.
> 
> 
>I hoped for a bit better reception since I have nothing against SGML, and PSGML  
>isn't in anyway designed to replace or insult it.  It is meant to be very  
>similar to the `C' preprocessor: handling needs people may have that are only  
>mildly related to the target language.  If you don't have the needs, it doesn't  
>hurt anything.  

Mark it seems you are confusing SGML the standard with a 
macro processor/text formatter. SGML doesn't "do" anything. It is a standard 
for the interchange of information that is application/hardware independent.
Again, may suggest that you spen less (no) time inventing(re-inventing) the
standard and work on improving/creating tools that handle the standard. We NEED 
them.  

If you really want to create another macro/formatting program make sure it
handles SGML as well.

>  ...   I wanted comments from "SGML people" to see how much they  
>really think I violated or interfered with SGML and to help keep PSGML in line,  
>but the responses didn't go in that direction.
>    
>To summarize why I even started the PSGML project:
> 
>   1)   I have numerous documents I want to convert to SGML while still
>        being extremely readable in the source form. I also want 
>        document conversion to be mostly automatic, so the documents 
>        should be fairly "sticky" both aesthetically and structurally.
>

Your use of "convert", "conversion", and "automatic" reveal the desire
to write a program as opposed to use a standard.

>   2)   I want to use popular public DTDs (QWERTZ, TEI, etc.) without
>        modifying them significantly, so the DTDs should be very
>        sticky.

I think Erik has sufficiently pointed out that the QWERTZ DTD may not be very
desirable. It helps no one to perpuate a poorly or archaic DTD. In fact it
perpuates the idea that the SGML concept may be faulty.

> 
>   3)   When modifying the shortrefs for SGML to handle these documents, 
>        it was impossible to handle many of the structures as nicely 
>        as I wanted.  Also, modifying the shortrefs for a DTD requires
>        rewritting that section of the DTD, not just adding to it.
>        

There are things I don't like about SGML as well but I have other problems and
deadlines that preclude me from re-inventing things because they contradict my
opinion of what is "nice" or "aesthically pleasing."

>   4)   Since I was concerned with a problem for hundreds of documents,
>        I attempted to generalize simple solutions for specific problems 
>        I was encountering.

SGML is ideal for handling hundreds (and more) documents.

> 
>    1)  Spaces between a tag and the next non-space character on the
>        same line are significant (no matter what).  This prevents 
>        visual space separating tags from "important" directly readable
>        information.  It also prevents aligning multiple rows of data
>        that are more readable aligned (when tags are different 
>        lengths).
>    

I thought Erik covered this?

>    2)  Spaces at the beginnings of lines are significant (unless a 
>        shortref removes them for that particular structure).
> 
>            2a) The shortref is structure dependent, and not document
>                flexible, so not formatting flexible.  If you actually
>                try to deal with this problem, you will see this to be
>                significant.
>            

Exactly! SGML was designed to be insensitive to formatting. It is not, I
repeat, It is not a formatting language. It is a standard for describing and
labeling the content and structure of information. It is not a macro language.
It is not a formatting language.

>    5)  Alternate tag names and multiple tags can not be used.

Exactly! It's hard to be rigorous if you allow tags different from those
defined in the DTD. Tags are supposed to be unique, just like variable names
and function names. 
I'm not sure what you mean when you say multiple tags cannot be used. You can
use as many tags as you want. 

> 
>            5a) A possibly document specific GI (like <fable>) can
>                not be converted to another GI (like <section>), nor
>                can it be converted to multiple tags (<section><heading>).
>                Nasty DTD GIs can not be renamed.
>            

Of course not! SGML doesn't "do" conversions. It is the application that must
do this. This is very important. It allows information producers to remain
ignorant of information users. How should I know, as a producer of fables that
somewhere down the line in time or space you would like to make one of my
fables part of one of your sections. Since data often outlives both the
software and hardware it was produced on (and often the author as well) we need
a way of rigorously annotating the information without be bound by imagined
uses. SGML provides this mechanism, "platform independant data."

>            5a) An omitted tag can not have empty content without
>                SGML complaining.

SGML doesn't complain. The parser might. Besides even C compilers complain if
you declare a variable and then don't use it. This is a feature not a fault.
Besides, SGML does allow tag omission if you say so in the DTD.

>    7)  Entities can not have alternate names, and can not have most 
>        special characters in them (without a major change to the 
>        DTD):
>            &C++;   &:-);   
>        are not allowed.

Again, this is a feature not a fault. Punctuation characters are not always in
the same place or have the same meaning. 
Besides, I believe you can redefine the Concrete Reference character set to
allow the inclusion of other characters.
It would be better to use:
	&cplus; &face;
anyway, because you don't necessarily know your audience (remember the stuff
you write may very well outlive you or the current programming language fad) A
novice reader can identify &face; yet not recognize colon-hypen-left paren.

>    
>    8)  The closed entity form:         stuff stuff &stuff; stuff.
>        can be less readable than:      stuff stuff \stuff/ stuff.
>    

Non-problem.

>    
>    9)  Using entities for accents and fractions is visually unpleasing.
>    

You have a good point here. However who ordained that e^' is more visually
pleasing. I must re-iterate that instead of spending time trying to improve
SGML why not write an editor that displays the characters in their recognized
form but records/stores them using SGML. We could really use a good public
domain SGML editor, whereas we really don't need yet another variant standard. 

>    14) Tag/entity macros can not be designed in SGML.  This isn't to say 
>        we should have really complicated macros, but the statement:
>            <=identitymatrix 4 4>
>        is both easier to type and read than expanding it out (at least
>        if it is not typeset).
> 
>    15) Some documents have hyphens at the ends of lines which should be
>        removed (and the hyphenated syllables concatenated).

This is a formatter problem not an SGML problem. There should be no hyphenated
words in the SGML source text. Hyphenation is a concept designed specifically
to fit more words on a page. It really has no place in the electronically
stored document. That why Knuth went through all the trouble to come up with a
good hyphenation algorithm so that hyphenation could be decided at print time
taking into account the current page, line, and type-size variables.

> 
>The generalized solutions I worked out:
>    1)      Alternate form of tag open and close that indicates spaces before
>            or after a tag are insignificant.  This looks almost identical
>            to SGML, and so is not very distracting.

It is distracting if you know the standard and tosses out the window the
consistency that SGML brings to the table. Besides you can change the tags
"look and feel" in the DTD.

>        
>    2,3)    Spaces at the end and beginning of lines can be removed by
>            PSGML.  This is the default mode since these spaces are rarely
>            intended.  It can be turned off if desired, or spaces can be
>            protected in several simple ways.

See, here's what I mean. PSGML is a formatter, SGML is not. 

>            
>    4)  Removing blank lines dependent on the following tag is 
>        impossible ...
>    4)      PSGML can be told to ... 
>    5)      PSGML can remap tags ... 
>    11)     Newlines can be removed by PSGML ...
>    12)     PSGML can convert a ...
>    15)     PSGML has a mode to convert these hyphens.
>    14)     PSGML has macros ...

This is a formatter not a data interchange standard.

>    9)      PSGML has a form for accents similar to TeX allowing: 
>                ^'o     -->     &oacute;
> ...

None of these are "more visually pleasing."

>    10)     PSGML has a simple form (common to many computer languages) 
>            for the printable entity of a special character:
>                \@      -->     &commat;
>                \^      -->     &circum;

I think this is already available. 
The semicolon is optional anyway if the entity reference is not embedded 
in another word.

>    14)     PSGML has macros, but they are implementation dependent

Please. We have more than enough implementation stuff as it is. That's why
we're promoting SGML.
We want to get as far away form "implementation", "platform", "version", etc.,
dependency as possible.

Write an editor, write a macro-processor (in generic code). Write Emacs macros,
WordPerfect macros/style sheets, MS-Word macros/style sheets, or better DTD's.
But please don't write yet another variant standard.

I really do appreciate your efforts. I sympathize with your feelings (I, for
example, want to write yet another SGML parser.) But I've spent more than a
decade dealing with variant this or that. I currently must support hundreds
of people on 4 different operating systems, using almost a dozen different 
wordprocessors, and 4 different Desktop Publishing systems, and three 
different network types, and they all want to share data!

Bend, don't break. Build on another's foundation. Don't re-invent the wheel.

Perry Sandoval
sandoval_perry@allin1.adpdp2.lanl.gov


Newsgroups: comp.text.sgml