xerces-j-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <Stephen.Kes...@orionhealth.com>
Subject Re: XMLSerializer Writer Constructor
Date Tue, 26 Jul 2005 20:20:33 GMT
Stanimir Stamenkov wrote:

> Why should I suffer from unnecessary encoding (done by the serializer) 
> then decoding (on my part), further handling character references 
> generated during the first encoding phase (eventually)?
> Seems I'm not following you here. Why one should make a 
> 'WriterOutputStream'?
> Again, if one needs to serialize to a byte stream then he needs to use 
> the 'OutputStream' argument constructor - why should he create an 
> 'WriterOutputSream' and pass it to the 'Writer' argument constructor, 
> loosing the extra care the serializer does when writing to a byte stream?

What I mean is an opposite to OutputStreamWriter - ie, something that 
takes a Writer and wraps it as an OutputStream - then it would seem 
rather natural to beginners to use the constructor, and provide an easy 
alternative for advanced use. 
However, that would not answer your first encoding decoding problem 
(although I'm not sure what would drive it).

Eric J. Schwarzenbach wrote:

>This has been discussed in these lists before.
>However there is one practical problem with deprecating this method. We
>cannot assume the developer is serializing to something under his
>control and that he has the option of constructing a Stream or a Writer.
>He may he interfacing to another system which provides him only a Writer
>to serialize to. OutputStreamWriter offers a bridge from OutputStreams
>to Writers but as far as I know there is no bridge the other way.
Well, I have a new (and betterer!) idea.  Is it possible to remove the 
OutputFormat argument?  I reckon that's dishonest.  I would suggest 
enforcing something like:

Document doc = ...;
Writer output = ...;
OutputFormat format = new OutputFormat(doc, encoding, true);
new XMLSerializer( output ).serialize(doc.getDocumentElement);

This way, it enforces that the user understands what they are doing, and 
does not take an encoding and do practically nothing with it.  And it 
would be fail-fast - if they didn't add the header, they would know 
about it pretty quick [as opposed to the current situation...].

Or, a boolean could be added to the writer constructor to specify 
whether to encode the output - that would at least force the question 
"what on earth is that boolean there for?".

See? Two easy and declarative options that indicate what it would do 
:).  Plleeeeeeeeeaaase deprecate!  If nothing else, it annoys me to see 
a dishonest api.

Ok - thank you both for your time - I wish I could have just searched 
the archives to pick up the argument for the reasoning behind it.  I 
hope this has been thought provoking for you guys.



To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org

View raw message