Date: Thu, 6 Jun 1996 13:04:20 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Greg Lehey <grog@lemis.de> Cc: FreeBSD Documenters <doc@FreeBSD.org> Subject: Re: Linuxdoc Message-ID: <Pine.NEB.3.93.960606123633.422D-100000@Fieber-John.campusview.indiana.edu> In-Reply-To: <199606061652.SAA03920@allegro.lemis.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Jun 1996, Greg Lehey wrote: > > Hmm... Not necessairly, but incremental changes would have to be > > applied horizontally across the whole document---while having > > some sections written up in docbook and others in linuxdoc may be > > possible, it would be orders of magnitude more difficult than > > making changes all at once. > > We need to discuss that statement. I don't see that it's true. Sure, > each file should have only one kind of format, but the individual > files could have different formats. At the moment, we have one of at While the handbook is seprated into many files, only one component in the system knows that, the SGML entity manager. When the parser encounters an entity reference, it just hands it off to the entity manager which returns the data. The parser does not no and does not care where the data came from. It could have been a distinct file, it may be just part of a file. It could be a stream read from a network socket. Only the entity manager knows. Now, it is possible to embed a subdocument with a different doctype inside a document but that isn't practical for our purposes because there is an inpenetrable wall between the two. In particular, cross references don't work across doctype boundaries. In fact, the sgml parser currently in FreeBSD implements subdoc handling be simply forking and calling itself to handle the subdoc. Possible, yes. Practical, no. > > Mix and match is only possible if you hawe two well designed, > > modular DTDs. > > I must be missing something here. If I am, please fill me in. All the elements of a document can usually be lumped together into various categories, sectioning elements, list elements, paragraph type element, tables, etc. If you have two DTDs that are designed in a modular fashion, it isn't difficult to create a hybrid DTD. In fact, this is a good thing because otherwize you end up with DTDs with a lot of redundancy, or a single DTD that is horrendously complex. With modular DTDs, you can pick and choose what you want. You may want the same table and list elements in most all documents, but the general structure for books, memos, articles, man pages are all quite different. With modular DTD parts, you write a manpage outer structure, and just plug in the tables and lists. One way to approach transfer from linuxdoc to docbook is to import a bit of the docbook DTD, say lists, and convert all the lists into that format. Next, bring in docbook sectioning elements, and so on until what was the linuxdoc DTD is now a proper subset of docbook and behold, you can simply call it a docbook document and ditch the old dtd. -john == jfieber@indiana.edu =========================================== == http://fallout.campusview.indiana.edu/~jfieber ================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.93.960606123633.422D-100000>