Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
