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
