org.apache.xerces.printer or org.apache.xerces.serialize? I'm going to add LexicalHandler support to get CDATA and comment working.
arkin Scott Boag/CAM/Lotus wrote: > > OK, I vote to go ahead and put this into the xerces project (I would still > like to re-evaluate the package placement down the line...) as soon as is > possible, and start working on getting this integrated into Xalan, so we > don't do any more redundant work on the FormatterListeners. I would like > to start integration, like, tomorrow (well, maybe the day after...). > > Assaf, if possible, I don't want to point to any > org.apache.xerces.serialize code if possible, except for the factory (which > I'll put in the xerces liaison), so I'm not sure about the > DocumentHandlerEx thing you mentioned. It would be good if you could add > implementation of the SAX2 LexicalHandler, or perhaps derive from > HandlerBase. > > Does anybody have any new news on SAX2? > > -scott > > > Assaf Arkin > <[EMAIL PROTECTED] To: [EMAIL PROTECTED] > e.com> cc: (bcc: Scott Boag/CAM/Lotus) > Sent by: Subject: Re: [Proposal] Printer > package > [EMAIL PROTECTED] > office.com > > > 11/15/99 07:13 > PM > Please respond > to xerces-dev > > > > The pattern list also recommends serializer. > > arkin > > Scott Boag/CAM/Lotus wrote: > > > > > b) If XML serialization support for beans comes along, and I know many > > > have requested it, this will create a confusion in names > > > > I'm not sure why. It's the same basic process. > > > > > I think printer and parser match, but how about just output? I guess > > > formatter is not descriptive enough either. What would be the opposite > > > of parse, by the way? > > > > Output is almost OK. I kind of like "formatter" (which is why I named my > > classes FormatterListeners). > > > > Stefano, myself, and James Tauber tried to come up with some design > > patterns a while ago: > > > > Abstract patterns: > > > > Producer ................... whatever -> memory > > Transformer ................ memory -> memory > > Pipe ....................... (Transformer)+ > > Consumer ................... memory -> whatever > > Chain ...................... Producer -> Pipe -> Consumer > > > > Pattern implementations: > > > > Parser ..................... stream -> API > > Processor .................. API -> API > > Formatter .................. API -> areas > > Renderer ................... areas -> screen > > Serializer ................. memory -> stream > > > > where > > > > API := [SAX | DOM] > > areas := memory representation of formatting areas > > memory := [API | areas] > > > > so that > > > > A parser is a producer > > A processor is a transformer > > A formatter is a transformer > > A serializer is a consumer > > A renderer is a consumer > > > > and name equivalences are > > > > processor = filter > > serializer = output-handler = emitter > > > > Notice that "Formatter" is used for the process of formatting to some > sort > > of area. emitter? > > > > I *really* like the idea of coming up with some sort of design patterns > > list that we can all stick to (doing this is Stefano's original idea... > so > > all credit goes to him). I don't know if the above is it, but I think a > > proper vocabulary will help a lot in having clean overall designs that > work > > with each other and that are understandable. > > > > -scott > > > > > > Assaf Arkin > > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > > e.com> cc: (bcc: Scott > Boag/CAM/Lotus) > > Sent by: Subject: Re: [Proposal] > Printer package > > [EMAIL PROTECTED] > > office.com > > > > > > 11/15/99 05:11 > > PM > > Please respond > > to xerces-dev > > > > > > > > > Serialization doesn't have to have anything to do with beans. The fact > > > that they used 'serializable' is just an artifact of their > > implementation. > > > > a) For me serialization does have to do with beans > > > > b) If XML serialization support for beans comes along, and I know many > > have requested it, this will create a confusion in names > > > > > > 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. > > > > I think printer and parser match, but how about just output? I guess > > formatter is not descriptive enough either. What would be the opposite > > of parse, by the way? > > > > arkin > > > > > > > > -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 > > > > -- > > ____________________________________________________________ > > Assaf Arkin [EMAIL PROTECTED] > > CTO http://www.exoffice.com > > Exoffice, The ExoLab Company tel: (650) 259-9796 > > -- > ____________________________________________________________ > Assaf Arkin [EMAIL PROTECTED] > CTO http://www.exoffice.com > Exoffice, The ExoLab Company tel: (650) 259-9796 -- ____________________________________________________________ Assaf Arkin [EMAIL PROTECTED] CTO http://www.exoffice.com Exoffice, The ExoLab Company tel: (650) 259-9796
