[
Lists Home |
Date Index |
Thread Index
]
I shot off my response too quickly, earlier, and didn't respond to all
of your questions. My apologies.
Aleksander Slominski wrote:
<snip/>
> here some of my observations:
> * both APIs supports full XML infoset and XML namespaces but by reading
> Swan API and code i could not figure out if Swan will auto declare
> prefix for unknown namespace (XmlSerializer will generate xmlns:prefix
> declaration thus leaving user from need to deal with namespaces prefixes
> but still allows to setPrefix() manually if desired so)
Swan lets you specify either a QName or a namespace URI/local name pair
when creating an attribute or element. If you specify a namespace
URI/local name pair, swan will derive an appropriate prefix from the
namespace mappings in scope. However, it will not automatically create
namespace declarations, if that's what you mean. I started down that
path, but was able to identify too many edge cases where doing this has
bad side effects and breaks code. If I disallowed using a QName for
element or attribute names, I could make this work, but I wanted to
allow QNames, and I didn't see a real compelling need to generate
namespace bindings.
> * Swan depends on SAX but XmlSerializer is completely independent
> interface that can be used without SAX (though XmlSerializer could be
> made to work with SAX easily)
Use of SAX was a conscious decision. SAX is a ubiquitous API, and by
using SAX, output from Swan can be easily piped into other handlers. For
example, using TrAX, I can direct Swan output through an XSLT
transformation, without having to write it out to a stream and reparse
XML from that stream. Using TrAX, I can also direct output to a
DOMResult and use Swan to build a DOM document or subtree. SAX provides
a great deal of flexibility with regard to what happens with the output.
> * XmlSerializer API is interface based but Swan is POJO and that makes
> harder to write interceptors (for example to add aspects to XML output
> code and that is quite common need) or create alternative implementation
> of API (if one would like to enhance Swan and not just use different
> LexicalHandler)
It would be easy to provide mechanisms for filters or "interceptors",
but I just felt that was overengineering things. I felt one could filter
the SAX events, and there are already many OTS utilities that can do
useful things with SAX events.
> * XmlSerializer is very simple - just one interface and Swan has 11 classes
> * XmlSerializer is very small - interface + implementation (MXP1) is
> 10K, Swan is 40K
> * XmlSerializer protects against mismatched endTag() calls by requiring
> endTag() to declare what is its corresponding startTag() and that pays
> off when writing a lot of XML in large applications. it seems that Swan
> allows only end() call that will close any current context and that can
> easily lead to hard to find errors ...
The end() does not need to be invoked for there to be a balancing end
tag. Results are not simply written to a stream, but are appended to an
axis belonging to a parent result. That parent result ensures that the
closing end tag is always emitted in the right place. The end() method
does not tell the ElementResult to add an end tag; it tells it to flush
all of its content (including emitting the end tag), and "close" itself
to any further additions.
<snip/>
> how Swan allows to control indentation - i believe that Swan example
> code will put everything in one line?
I don't provide explicit support for that. One can easily use it in
conjunction with TrAX for massaging output, though. The ResultFactory
class is a convenience class that makes it easier to use Swan with TrAX:
ResultFactory factory = new ResultFactory();
// indent output
factory.setOutputProperty(OutputKeys.INDENT, "yes");
// output to TrAX StreamResult
StreamResult output = new StreamResult(System.out);
DocumentResult doc = factory.newDocumentResult(output);
// ... now create our output
There is a core set of standard output properties that all TrAX
implementations support. In addition, individual TrAX implementations
innovate by offering their own extensions to the standard set.
Developers can shop around for their preferred TrAX implementation and
swap it in to use with Swan. They are not constrained to just that
functionality that Swan provides. For instance, I'm using it with SAXON.
SAXON has an xhtml output mode that massages your output and makes sure
it is XHTML with the appropriate stylistic conventions to be friendly to
legacy browsers.
|
