X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil] [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) Date: Wed, 2 May 90 16:36:00 GMT Reply-To: LaTeX-L Mailing list From: "Chris Rowley - Open University UK (R01/Maths)" Subject: Re: Frank's latest To: Rainer Schoepf Status: R X-Status: X-Keywords: X-UID: 88 > I hope everybody of you is eager to grap one of the > classes and make a first proposal which can then be > discussed on this list. I have in front of me at present a list of about 15 document classes for which I have to do just this. When I have finished that lot I shall at least have some experience!! This also means that my responses now will be brief. > Nico is right that we can learn from SGML (at least in some > sense) and what I want is to discuss the different DTD's. > In SGML language one can make a model which describes what is > allowed in what order and so on. The SGML parser will than check > if the document conforms to this model. > In my opinion such checks should not be made by LaTeX but It is probably not necessary to make all such checks but some should be made, if only as part of improving LaTeX's error correcting/reporting ability (see my earlier contribution on this). > nevertheless it might be a good idea to discuss DTD's or > (document classes as I call them) in SMGL like syntax. The question > is whether everybody is familar enough with this syntax? > > Another approach could be to make simply a list of commands > together with some comments what the macro is supposed to do and why. > We should not forget that in the end we have to convert things > anyway into LaTeX language. SGML notation will not help with the "what it is supposed to do", so if this is required, we shall need something extra. I vote for something not too formal but clear. We also need to be careful to distinguish between the "logical tags" and the "formatting information": it is not at all clear to me that all the latter can be left to the style files, although much of it should be. To illustrate, look at Frank's example (I know it is not intended to be necessarilty real or complete): > Commands for describing a titlepage in an article: These are not, in fact, describing "a titlepage", but providing a class of information about the document: a full description of them would need to go further and say what type of information they should supply---some examples: can the "text" of each of these entities (SGML jargon) contain line-breaks or unbreakable_spaces ? Both of these are formatting information, but in the case of author_address, if it is "conventionally formatted", the line_breaks also give logical information, as does the punctuation etc in the date. if they do contain formatting information, is the style obliged to take notice of it? > title_long Title which is used on the front page > title_short Title for running headings (default title_long) > > author_name Separate the old \author command > author_address > author_netaddress > > Multiple authors could be handled by repeating the above commands > with some syntax for allowing defaults (same address and so on) > > date (default processing day i.e. \today) > The old \maketitle command is, in my opinion, not necessary because > the placement of the title information should be determined by the > style (for example authors address at the end). I agree that this should be the way it works but this is quite a large change from the way in which LaTeX at present treats such information, so there may be upward compatibilty problems(??) (but this is a side-issue at present). > and so on .... > ....... strong agreement!! > When I said in one of the last messages that I think that there > is not enough response on this list I really meant it. Agreed, and I plead guilty (but it is not the only thing I have not had time for!!). Clearly the first thing we must implement is a good e-mail version of "box-ticking": any ideas? chris