Cocoa beta release: XML Nanny

I’m proud to announce the release of a preview version of my new Cocoa app: XML Nanny.

This is version 0.8 of XML Nanny, and it’s missing some polish and important features, but “release early, release often”, right?

XML Nanny is basically a Cocoa port of my desktop XML Well-Formedness/Validity checker application, GooeySAX. Whereas GooeySAX was written in Java with a Swing interface, XML Nanny is pure Objective-C and Cocoa (with a little bit of JavaScript and AppleScript thrown in for sass). The application is targeted at developers who need to:

  • Check the well-formedness or validity of XHTML documents over the network, or behind a local firewall (which would prevent the use of say, the W3C’s web-based XHTML validation service.
  • Check the well-formedness or validity of XML config files. For example, I’m constanly using GooeySAX to check the validity of my web.xml and faces-config.xml servlet and JavaServer Faces config files.

Basically, anytime you need to check an XML doc for well-formedness or validity (which is quite a lot these days), something like XML Nanny comes in very handy.

So the most consipicuous missing XML Nanny feature in this beta release is the lack of support for validating your XML document. You can currently use XML Nanny to check your document’s well-formedness but not its validity. In other words, you could make sure that you closed all your tags and quoted attributes properly, but you couldn’t assert that you hadn’t placed elements in inappropriate places, like say a misplaced <p> tag inside the <head> tag of an XHTML document.

Unfortunately, that severely limits XML Nanny’s usefullness at the moment, as the greatest potential audience for the app are standardista web authors trying to validate their XHTML pages. The good news, is that this feature should be up and running by the end of the week, maybe even in a couple of days.

Another currently missing feature is the ability to select XML documents on your local disk for parsing. As of this version, you can only type in the URL of a file using the http protocol.

So why are these features missing? Cuz I started the project yesterday morning. Cocoa development is so fast! Especially when compared with my experiences with Swing — which for the record, were certainly not unpleasant… just not as nice as Cocoa ;).

There is one really cool feature of XML Nanny that is currently implemented… When you parse an “XML document” that has well-formedness errors, a list of one or several parse errors appear in the XML Nanny result display (which is actually an embedded instance of the Safari browser rendering engine, Web Kit). Each of these error items is a special hyperlink back to the document you were checking. By clicking one of the error items, a new Safari window will be opened and loaded with your document. Then, if your document was XHTML, the general region of the well-formedness error will be given a noticeable, thick red CSS border to show you roughly where in the document the error occurred. This is a great time-saving feature for checking XHTML documents!

Here’s how it works… as XML Nanny parses your XHTML document, it stores a list of all the HTML id attributes it encounters. When it finds a well-formedness error, it creates the error item in the results display (which is really just an HTML <li> element with some CSS, and gives that item a special onclick JavaScript handler. That handler calls Safari via AppleScript (by way of Objective-C), and then highlights the element with the last HTML id attribute it had found before the parse error. So if you have a lot of HTML ids sprinkled throughout your XHTML document, this visualization could be highly accurate, and lead you much more quickly to the source of the problem than some lengthy error message or code block. A picture is worth a thousand words.

As I mentioned, the main results display list in XML Nanny is an instance of the same web content rendering engine that powers Safari, called Web Kit. As of Mac OS X Panther, Apple has exposed the Web Kit API to Cocoa developers. Embedding Web Kit is a great way to create a highly sophisticated GUI in a portion of your Cocoa app without resorting to a lot of low-level 2D painting and drawing. In some instances, using a 2D API can be great, but for most common needs, developers have a much easier time building a mini web page with CSS and JavaScript. So I decided to use Web Kit for the results display. It just shows a single web page that is included in the app bundle, and then uses the Objective-C DOM API exposed by Web Kit (as of Mac OS X 10.3.9) to tinker with the <li> elements in the page. The CSS style for the elements is specified in the XHTML document that is being displayed just like any normal webpage, and is picked up automatically when new elements are added (also just like a normal web page).

As for the XML parsing, XML Nanny uses Apple’s SAX-like XML event push API, NSXMLParser. As far as I can tell, this is the main Objective-C XML parsing API. Surprisingly, NSXMLParser is a non-validating parser which limits its usefullness. This is also why XML Nanny does not yet support validation. There are a couple of open-souce Objective-C SAX ports, but they don’t look to be well looked-after. It appears that if you want to validate an XML document using Apple’s standard Objective-C APIs, you have to use their Tree-based API… the similarly named, yet unrelated NSXML API. This strikes me as a hole in the Cocoa toolkit… generating a full-blown Document tree just to validate a document is a bit wastefull. I’m guessing that most people take advantage of the ability to freely mix C++ and Objective-C by including some C++ SAX API when needing to do event-based XML validation from a Cocoa app. Any Cocoa developers reading who can confirm?

Expect a more full-featured 1.0 release by the end of the week. After that, I’ve got lots of ideas for AppleScriptability for the app, and a small suite of Automator actions to go along with it.

About this entry

You’re currently reading “Cocoa beta release: XML Nanny,” an entry on Todd Ditchendorf’s Blog.

Published:
08.21.05 / 9pm
Category:
AppleScript, Cocoa, Mac OS X, Objective-C, XML