I don't have a problem granting commit access to folks who are going to work on the code.
----- Original Message ----- From: Scott Boag/CAM/Lotus <Scott_Boag/CAM/[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Monday, November 15, 1999 12:59 PM Subject: Re: [Proposal] Printer package > Download a separate package containing just the code under > org.apache.xerces.printer and use it. You need DOM and SAX in the path, > but you don't need the parser. That sounds like it ought to be a seperate package to me. See my note to Ted about commit access issues. > I like printer better ;-) Why? To me, printing is the process of outputting to hardcopy. I think it is a confusing term to use for this process. People are going to look at that package and think it is going to send output to their LaserPrinter. Since 'printing' is likely to be often used in document processing, I think another term would be better. Main Entry: (superscript: 2)print Date: 14th century transitive senses 1 a : to impress something in or on b : to stamp (as a mark) in or on something 2 a : to make a copy of by impressing paper against an inked printing surface b (1) : to impress (as wallpaper) with a design or pattern (2) : to impress (a pattern or design) on something c : to publish in print d : PRINT OUT; also : to display on a surface (as a computer screen) for viewing 3 : to write in letters shaped like those of ordinary roman text type 4 : to make (a positive picture) on a sensitized photographic surface from a negative or a positive intransitive senses 1 a : to work as a printer b : to produce printed matter 2 : to produce something in printed form 3 : to write or hand-letter in imitation of unjoined printed characters > serializer is out of the question. Why? What we are doing is serializing events or a tree to a character stream. > If you want to > really serialize documents that would probably fall under the scope of a > different product (e.g. how to serialize Beans and not just DOM?) Serialization doesn't have to have anything to do with beans. The fact that they used 'serializable' is just an artifact of their implementation. Main Entry: se�ri�al�ize Pronunciation: -"lIz Function: transitive verb Inflected Form(s): -ized; -iz�ing Date: 1857 : to arrange or publish in serial form - se�ri�al�i�za�tion /"sir-E-&-l&-'zA-sh&n/ noun > xmloutput seems redundant, unless we should > consider xminput. I was only using xmloutput because it was similar to xsl:output. I'm not in love with either of my suggestions. I just find 'printer' to be confusing and not very descriptive. -scott Assaf Arkin <[EMAIL PROTECTED] To: [EMAIL PROTECTED] e.com> cc: [email protected], (bcc: Scott Boag/CAM/Lotus) Sent by: Subject: Re: [Proposal] Printer package [EMAIL PROTECTED] office.com 11/15/99 03:34 PM Please respond to xerces-dev > I don't think this is a good assumption. In my view we are making > components, which should be standalone. For instance, Xalan is useable > without any parser at all, though this tends to be an unlikely scenario. > It is certainly designed not to have tight coupling with Xerces. I took that into account, I can certainly imagine someone using Xalan without Xerces and then the dependency becomes a problem. The design right now is that you can download the printers separately of any given DOM and use them. Possibly: * Xerces only distribution + printers/utility classes * Xalaon only distribution + printers/utility classes * Combined distribution (Yes, I don't like this approach, am looking for better solutions) > > or can obtain the > > printer/utility packages separately. > > Not sure what you mean by this. Download a separate package containing just the code under org.apache.xerces.printer and use it. You need DOM and SAX in the path, but you don't need the parser. > What do you think about changing the package name from .printer to > .serializer or .xmloutput or the like? I like printer better ;-) xmloutput seems redundant, unless we should consider xminput. serializer is out of the question. If you want to really serialize documents that would probably fall under the scope of a different product (e.g. how to serialize Beans and not just DOM?) > We'll also need a raw text output. I can adapt my FormatterToDOM to use > straight SAX, so this won't be a problem. That's a boring printer, so I left it for last ;-) arkin > > -scott -- ____________________________________________________________ Assaf Arkin [EMAIL PROTECTED] CTO http://www.exoffice.com Exoffice, The ExoLab Company tel: (650) 259-9796
