Serializing vs. Pretty-Printing

[Andy Clark <an...@apache.org>]

Due to some recent discussions, as well as using the current 
serialization code, I want to start some discussion on what
it means to serialize versus pretty-print XML. 

Currently the serialization code is a pretty-printer. This
is causing a number of issues to come up. For example, the 
pretty-printing actually writes a document that is different 
than the one in memory (either through SAX or DOM). Is this
what we want? Could this cause problems with validation when 
reading the now serialized document?

I would suggest that the serializers be layered. The base
serializer should only print what is on the SAX stream or
in the DOM tree, nothing more. Then a pretty-printer can
extend this base implementation in order to make the nice
output that we currently have.

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org

Re: Serializing vs. Pretty-Printing

[Assaf Arkin <ar...@exoffice.com>]

Andy Clark wrote:
> 
> Assaf Arkin wrote:
> > People are running into troubles with pretty printing not because it's
> > works without asking them, but because they enable it specifically.
> 
> Well then that's a simple matter of getting some documentation
> for the serializers into the FAQ. Just looking at the objects
> and their constructors, I was unaware that you could create a
> serializer from SerializerFactory without specifying an output
> format. Or is that you can setup an output format object that
> tells the serializer not to pretty-print?

You can create a serializer with a default OutputFormat given just the
method name (xml, html, etc).

Also, if you create an OutputFormat unless you specify true for the
indenting argument or call setIndeting( true) it will not pretty-print.

If it does, it's broken :-)

arkin


> 
> --
> Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Re: Serializing vs. Pretty-Printing

[Andy Clark <an...@apache.org>]

Assaf Arkin wrote:
> People are running into troubles with pretty printing not because it's
> works without asking them, but because they enable it specifically.

Well then that's a simple matter of getting some documentation
for the serializers into the FAQ. Just looking at the objects
and their constructors, I was unaware that you could create a
serializer from SerializerFactory without specifying an output
format. Or is that you can setup an output format object that
tells the serializer not to pretty-print?

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org

Re: Serializing vs. Pretty-Printing

[Assaf Arkin <ar...@exoffice.com>]

The serializer has two modes of operation. Straight serializer and
pretty printer. You have to select pretty printing by using an
OutputFormat or a suitable constructor. It's off by default.

People are running into troubles with pretty printing not because it's
works without asking them, but because they enable it specifically.

arkin


Andy Clark wrote:
> 
> Due to some recent discussions, as well as using the current
> serialization code, I want to start some discussion on what
> it means to serialize versus pretty-print XML.
> 
> Currently the serialization code is a pretty-printer. This
> is causing a number of issues to come up. For example, the
> pretty-printing actually writes a document that is different
> than the one in memory (either through SAX or DOM). Is this
> what we want? Could this cause problems with validation when
> reading the now serialized document?
> 
> I would suggest that the serializers be layered. The base
> serializer should only print what is on the SAX stream or
> in the DOM tree, nothing more. Then a pretty-printer can
> extend this base implementation in order to make the nice
> output that we currently have.
> 
> --
> Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org