From lieber@ccs.neu.edu Tue Dec 29 21:20:52 1998 Received: from stockberg.ccs.neu.edu (lieber@stockberg.ccs.neu.edu [129.10.116.114]) by amber.ccs.neu.edu (8.9.1a/8.9.1) with ESMTP id VAA18490; Tue, 29 Dec 1998 21:20:51 -0500 (EST) Received: (from lieber@localhost) by stockberg.ccs.neu.edu (8.9.1a/8.9.1) id VAA11589; Tue, 29 Dec 1998 21:20:51 -0500 (EST) Date: Tue, 29 Dec 1998 21:20:51 -0500 (EST) From: Karl Lieberherr Message-Id: <199812300220.VAA11589@stockberg.ccs.neu.edu> To: dstrom@ccs.neu.edu, lieber@ccs.neu.edu Subject: Re: Project Update Status: R Hi Daniel: I looked at your new web page addition. Looks very good. I noticed that you even generate look-ahead definition in the generated cd. Please can you describe how you generate the look-ahead clause. omparing your DTD and the generated cd, I did not understand why you have several intermediate classes of the form _grp_ What was the reason for generating them. Please put this into your doc. Please can you comment on whether this way of producing a text processing system is easier than writing it in Java. You probably can only answer this when you have generated some interesting beh files from XSL files. >From dstrom@ccs.neu.edu Tue Dec 29 12:28:37 1998 >Received: from denali.ccs.neu.edu (dstrom@denali.ccs.neu.edu [129.10.116.200]) > by amber.ccs.neu.edu (8.9.1a/8.9.1) with ESMTP id MAA00593; > Tue, 29 Dec 1998 12:28:34 -0500 (EST) >Received: (from dstrom@localhost) > by denali.ccs.neu.edu (8.9.1a/8.9.1) id MAA00130; > Tue, 29 Dec 1998 12:28:33 -0500 (EST) >Date: Tue, 29 Dec 1998 12:28:33 -0500 (EST) >From: "Daniel J. Strom" >Message-Id: <199812291728.MAA00130@denali.ccs.neu.edu> >To: lieber@ccs.neu.edu >Subject: Project Update >Status: R > > >Prof. Lieber > >I have updated my web page. Please excuse the lateness. I will be ready to >turn this in by the end of the month. Good. > >I have changed the focus slightly. I have spent relatively more time on the >DTD and less on XSL than I originally planned. I did this because I realized >that XSL has evolved into a very large spec. The amount I could have done on >the XSL would still have been only a small subset. By concentrating on the >DTD, I have been able to do a very large subset of that (all the major pieces >are covered as I understand it; most typical DTDs should work). The XSL I >will be able to handle will be a small, but usable subset (font properties and >spacing). > Good decision. > >Earlier you asked a question I forgot to answer: >> Are you creating cd and beh files by printing them directly >> as text or by creating objects that you print with the >> PrintVisitor. > >I am printing them as text from inside a visitor as I traverse the DTD. I >can't really print them directly from the parsed tree using the PrintVisitor >(which works in a depth-first fashion -- see example below) and I felt it >would be more complicated to create a different tree just to use a >PrintVisitor. I agree. > >The reason I say I can't use a depth-first traverse for this is related to >input such as: > >Unless I missed something, this can't be converted into a single sentence but >instead must be converted in a series of statements such as: >... >A_grp7 = H . >A_grp8 = I . >A_grp9 = A_grp7 A_grp8 . >A_grp10 = ZeroOrMany(A_grp9) . >... > >A_grpN : E | A_grpO | A_grpP | A_grpQ . >A_grpR : A_grpS | A_grpT | A_grp10 . >A_grpU = OneOrMany(A_grpR) . >... >A_grpV : ... A_grpU ... > >which can't be conveniently done in a PrintVisitor. This does not sound right. You would create a new object representing all those class definitions and at the end you print them with the PrintVisitor. But I agree with you that often printing with print statements is easier than constructing a new object. > >I don't have the actual generated output for this at work, so this is similar >to what would be generated. Obviously, this could be optimized but this is a >relatively straight-forward automatic generation. > >If I've missed something, I would appreciate hearing about it (although I >don't think I could incorporate it into the project). > >Dan > -- Karl