Subject: Linux-Activists - DOC Channel digest. 94-1-9-6:12
From: "Linux Activists" <[email-masked]>
To: "Linux-Activists" <[email-masked]>
Date: Wed, 9 Feb 1994 11:43:34 +0200

Topics:
	 Re: Linux-Activists - DOC Channel digest. 94-1-8-5:5
	 Linux-Activists - DOC Channel digest. 94-1-8-22:23
	 Linux FSSTND 1.0 almost completed

----------------------------------------------------------------------

From: Thomas Dunbar <[email-masked]>
Subject: Re: Linux-Activists - DOC Channel digest. 94-1-8-5:5
Date: Wed, 9 Feb 1994 03:27:03 +0200

> > 3. Using SGML, HTML, or some other notation is not an option for me
> >    either, at this time: I have no tools, and no time to install or
> >    learn such.  However, experimenting with other formats is a good thing,
> >    and after others have done it, I'll be happy to follow.
> 
> I'm going to start looking at SGML. Once I have it all worked out, I
> can write up a short tutorial (it looks quite easy), even get a Linux
> binary distribution of the software you'll need.
> 
> It looks like the HOWTOs are going to move to SGML, so that will be
> my guinea pig. :)
> 

how about a little more precision here: i suspect that when people say
SGML, they actually mean the subset HTML+ and in particular the subset
of HTML+ understood by Mosaic. dont mean to be pedantic, just want to
understand what others mean.

 imo, current implementations of HTML+ can't produce good looking books.
What is needed is something more sophisticated than Mosaic to run the html
thru, say TeX. but then why not just keep the doc in LaTeX, taking care
to limit oneself to what's convertable by ones latex2html.

"is that what you're doing with your book?"   no :(
 
for one, i dont use latex. but primarily, i dont think it possible
to get decent hardcopy and screencopy for the same document. or at
any rate, if possible, no easier than just doing two different, but
related, docs.

"so what are you doing with your book?"

nothing right now..but i intend to convert it (now, before i get into
writing the main part) for good screencopy bias, and not worry about
hardcopy. that moves away from TeX, regretably, but works out better
wrt my emphasis on interacting with METAFONT.
 
That change fits nicely with Linux also, i think. after all, the 
global network is an essential feature of linux development..shouldn't
documentation for it be woven into the net, too?

course that means i wont see my book in print..no big deal. besides,
probably wouldn't anyway!

"so what?"

guess my main point is to argue that one must choose between good
hardcopy and good screencopy. what html+ offers is, for the first
time, good screen copy (formatting, links, annotations, graphics)
is possible in a portable format.

-- 
Thomas Dunbar           phone: 703 231-3938
Virginia Tech             fax: 703 231-3714
100C Sandy Hall           WWW: http://milieu.grads.vt.edu/

------------------------------

From: [email-masked] (Gavin Thomas Nicol)
Subject: Linux-Activists - DOC Channel digest. 94-1-8-22:23
Date: Wed, 9 Feb 1994 06:00:35 +0200

>I believe that the best choice for hypertext on-line documentation
>would be HTML because there already exists a variety of tools that
>can use it and there is also an editor for it in tkWWW I think.

I would recommend HTML+, because:

  1) It supports tables
  2) It will be the future HTML standard

However, it does not support figures (except inline stuff).

There are other alternative SGML DTD's. One can choose DocBook, QWERTZ
(which Matt favours), TEI's one, and a whole host of others. The
advantages of using HTML+ however are:

1) You get online browsing and fine-grained hypertext for free.
2) Converters already exist for it, and more will come.

The biggest disadvantage is that it is not all that pretty. I mean
using things like <h1> instead of <chapter>. 

Anyway, if anyone is really planning to do something with SGML, two
tools I would recommend looking at:

1) sgmls + qwertz
   This gives you a good idea of what an SGML publishing system should
   look like.
2) The Amsterdam SGML Parser
   This is a *very* flexible system for working with SGML. It converts
   a DTD into an LL(1) grammar, and then generates an executable
   parser for it. Like sgmls, it uses replacement files for conversion
   to other formats.

With these two tools alone, or possibly with addition scripting
language support, any conversion is possible.

One way or another, I think SGML is the way to go, and I must admit,
I'm biased toward HTML+, because I think it'll save a lot of work in
the long run. I don't see anything wrong with extending it somewhat to
support extra functionality, because the draft standard for HTML+
browsers states that they should ignore entities and elements they
don't recognise. This will allow the LDP to add whatever hacks they
desire, and *still* get SGML and hypertext in one file, which can be
easily converted to LaTeX for printing.

We had a similar discussion 2+ years ago, we wouldn't be having this
discussion now if people thought ahead a little then.

------------------------------

From: [email-masked] (Daniel Quinlan)
Subject: Linux FSSTND 1.0 almost completed
Date: Wed, 9 Feb 1994 06:52:02 +0200

While it isn't exactly documentation, the first public version of the
Linux filesystem standard is to be released within about a week.
Since it is already being used as a reference by many developers and
some Linux documenters have followed our progress, this notice is
being posted here in consideration of the DOC channel's readers.

In short, anyone who is interested can take an early look at this
standard from the FSSTND group (formerly of the FSSTND channel).

For those who are not yet aware of this long-term and comprehensive
effort, this abstract taken from the current draft should explain the
essence of it:

       The open and distributed process in which the Linux operating
     system has developed fosters rapid growth of the operating
     system, applications, and integrated distributions.  This
     decentralized process, however, has created a need for
     standardizing the structure of the filesystem.  This standard
     aims to define locations and specifications for files and
     directories in Linux systems.  This will allow users, developers,
     and distributors to assemble parts of the system from various
     sources that will work together as smoothly as if they had been
     developed under a monolithic development process.  It will also
     make general documentation less difficult, system administration
     more consistent, and development of second and third party
     packages easier.

The draft is available through anonymous ftp at
     tsx-11.mit.edu:/pub/linux/docs/linux-standards/private/fsstnd

In the "fsstnd" directory there is an ASCII copy (named according to
the date of the revision -- "draft-yy.mm.dd") and PostScript/DVI
copies of the most current draft ("draft.ps.gz" and "draft.dvi.gz").
Also, please note the "private" in that pathname (which won't remain
for long).

If you have any questions or comments, please feel free to direct them
towards me or any contributor listed in the standard.  Thank you.

Daniel Quinlan
FSSTND Coordinator

-- 
Daniel Quinlan  <[email-masked]>

------------------------------

End of DOC Digest
*****************
-------