> I have following follow-up questions, and would appreciate
> clearing my doubts:
>
> 1) Is it possible to pretty print the output?
Try transformerHandler.getTransformer().setOutputProperty(OutputKeys.INDENT,
"yes")
> 2) Is this approach faster than using DOM serialization?
Well, it should be, because it doesn't involve building a tree in memory.
But the only way to find out is to measure it.
> 3) Here I am using the transformer functionality for creating
> XML, which looks more like a XSLT feature (i.e., transformation task).
> Should we not have this capability in the XML parser (for
> e.g., in Xerces)? Should we have something like xml-writer
> (which Rob pointed) built into Xerces (possibly as an enhancement)?
It's hard to change history. XSLT processors include a serializer because
it's defined in the XSLT specification, and since they have one, it makes
sense to expose it even if you aren't doing a transformation. There's no
particular reason why a product whose primary purpose is XML parsing should
also include a serializer.
>
> At the end of all this, it struck to me, I should try
> violating the well-formedness constraint of XML and see what
> happens. And to my surprise, this technique also suffers from
> the same problem I mentioned with xml-writer. Why does the
> implementation doesn't ensure this?
Because the spec doesn't say it has to. And because XSLT serializers were
primarily written to get their input from XSLT transformers, which they
trust; so why incur the extra expense?
Michael Kay
http://www.saxonica.com/
