> 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




Reply via email to