Tool developers are fond of using XML for configuration files. This has many advantages: it provides a standard, universally understood syntax for configuration. It allows text editors and IDEs provide reasonable editing and highlighting features for files they do not understand. It makes parsing configuration very easy for tool developers.
The drawback is that XML is quite verbose. It requires a lot of keystrokes, and can be very difficult for humans to read.
SweetXML is an alternate syntax for XML, designed to make configuration files more concise and readable by adding a bit of syntactic sugar. It changes XML's syntax without changing its fundamental structure, so that it can work as a replacement for XML wherever readability is an issue.
The two are equivalent in that they have the same document structure when parsed. In other words, both XML and SweetXML have exactly the same constructs (tags, attributes, text, and entities) and yield exactly the same DOM or exactly the same SAX. After parsing, there is no distinction between them.
SweetXML is not XML in that it has a different syntax, designed to be more concise and human-readable in configuration files.
Because SweetXML has the same document structure as XML, it is a low-impact replacement. Tools can use it without needing to be aware of its special syntax; instead, a converter translates SweetXML to plain XML during the build process or at tool launch time, allowing SweetXML to work as a drop-in replacement anywhere XML configuration files are too verbose.
If a tool wishes to support SweetXML syntax directly, it can do it by inserting just a few lines of code to perform the conversion, and continue to use its existing XML parsing mechanism.
SweetXML achieves its conciseness by:
It looks like this:
access-rule message: "Only the model can talk to the persistence layer" deny to pattern="persist" allow from pattern="persist" allow from pattern="model"
In this example, "access-rule", "message", "deny", "allow", "to" and "from" are all tags. Several tags have a "pattern" attribute. The indentation determines how the tags are nested, so there are no closing tags. The colon on line 2 signifies text nested within the "message" element.
The user guide contains a complete description of the syntax, and more extensive examples.
It is good in most cases where:
Prime candidates are configuration files for Macker, Ant, Maven, Hibernate, Tapestry, servlet containers such as Jetty and Tomcat, app servers, XUL, JSF ... you get the idea.
It’s not good for computer-to-computer communication, such as XML-RPC or syndication feeds. In these situations, human readability is not a major issue — but interoperability is, and changing syntax seriously undermines it. Yes, in theory, "SweetXML-RPC" could save bandwidth, but in practice, it's a bad idea.
It’s probably not good in very performance-sensitive situations (i.e. processing thousands of documents per second). The SweetXML converters are reasonably fast, but not yet optimized for high performance.
It’s not good for formats such as XHTML which consist of large amounts of text interspersed with tags. SweetXML's focus is configuration files, and it is not well suited to marking up documents.
YAML is, in fact, the direct inspiration for SweetXML. The important difference between the two is that SweetXML has the same document structure as XML, while YAML has its own very different document structure. Unlike SweetXML, therefore, YAML does not work as a drop-in replacement for XML; adding YAML support to an XML-based tool requires substantial coding.
How do they compare? Let's forget for a moment about the various validation and transformation schemes (DTD, XSL and all that jazz) — SweetXML is for configuration files, and these things aren't what make XML configuration files hard to read and maintain. Instead, consider the document itself, since that's what we're really talking about here.
In spite of its conciseness, YAML actually has a much more complicated document structure than XML, with different constructs for sequences, unordered sets, key-value mappings, aliases, document separators, explicit node types ... and so on. XML documents have only tags, attributes, text, and entities; that's it.
The result: SweetXML's syntax and structure are both much simpler than YAML's, while YAML is more expressive. Neither is Pareto superior; there's a clear trade-off, which you should consider if you're choosing between them for your project. Simplicity is a virtue, and so is expresiveness.
A very similar analysis holds for JSON. It is more minimal than YAML, but still has more document constructs (arrays, pairs, and different data types) than XML. Its syntax is more complex, but more expressive. It is not a drop-in replacement for XML.
It provides converters in both directions between XML and SweetXML syntaxes. It also provides plugins to make the converters available in popular build tools (currently Ant and Maven). [These plugins are currently in development — see the roadmap.] The initial converters are written in Java, because Java tools tend to be the most enamored of the XML config file. Volunteers are welcome for ports to other languages, particularly Ruby and Python.
Once the syntax is well established, the project will also provide a syntax specification. However, the plan is to kick the tires for a while before nailing down the syntax.
Of course. It uses a BSD-style license, so you are free to bundle it in your application or tool.
It is currently in experimental development. The syntax is not yet stable. It is therefore not a good idea to switch all your projects over just yet, unless you enjoy being on the bleeding edge, and are willing to do some mop-up work if the syntax changes.
However, the code is certainly solid enough for experimental use. Try it on a side project, and see how it works. Early experiments before backward compatibility is an issue will be key to making the syntax as good as possible.
In short: don't put all your eggs in this basket just yet, but please try it out!
More details in the roadmap.
Binaries are available from the downloads area. Source is available from the Subversion repository.
There are several basic ways of using it. One is to add support for it to your application, by dropping in a converter into your input stream just before XML parsing.
If you don't control the code that is parsing the XML, you'll need to convert the SweetXML file to XML before it gets parsed — i.e. during the build process, or before launching a tool. Until tools start adding built-in support for SweetXML, this second approach will be far more common.
You can also do a one-off manual conversion just to try it out.
The user's guide explains these options in much more detail.
Try the SweetXML discussion group.
Yes. SOX and SLiP are both very similar to SweetXML.
Why build another option then, you ask? Aesthetic differences. SweetXML's author thinks it is more concise, easier to learn, and looks prettier. (He also talks about himself in the third person.)
Yes! Check the wiki for ideas on how to help.
It provides syntactic sugar for XML, thus making it sweet.
Paul Cantrell, who also plays the piano and has some other open-source projects.