Re: YAXOL [Re: [ANN] Small, simple Java-based XML ou
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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format