Norman Richards

I ♥ XML

We were brainstorming ideas for an XML Austin t-shirt after tonight's meeting. Keeping with the spirit of Austin, one of my early favorites was Keep XML Wierd. At least if our group of XML misfits is any indication, that's a pretty fitting slogan. My personal favorite was I ♥ XML. It's a joke only a true XML nerd would appreciate.

docbook at XML Austin

I'll be speaking on Docbook at tonight's XML Austin Users Group. (meeting info) I'll be talking about docbook, the docbook tool set and some of my experiences working with docbook for the last 6 months. Come check it out if you are in town.

Loading DTDs over the net

Loading DTDs over the net has to be one of the worst ideas ever. On a previous project we used to have random build failures when the network was a bit shaky. The problem is that parts of our build script and test code were loading the DTDs over the network instead of using a local version. Tracking down the places we were using DTDs without providing them locally was a real pain because we were never quite sure if we got it right without actually disconnecting from the network. It's easy to forget one, especially on a large team that uses a lot of XML. I wish parsers didn't try to load DTDs from over the network. It's a behaviour you really never want in a production system. Do you really want your app pinging some remote site over the net every time it comes up? Do you want your customers dependent on DTDs that reside on your corporate website?

We had an interesting issue at JBoss this week related to this. JBoss takes great care to make sure we use local DTDs, but we obviously can't control trools or documents with incorrect DTD declarations. We have been providing the DTDs on the website, but somehow the DTDs got removed when the corporate site was redesigned. Almost immediately people started complaining about failures from not being able to load the DTD over the network. If it were me, I'd be more concerned about why my applications are trying to load DTDs over the network than why the DTDs are missing. I'm not sure when the DTDs will be back live, but in the meantime it's a good opportunity to think about making sure your application doesn't depend on remote DTDs.

Naked XML

Eitan's presentation on Naked Objects last night at Austin JUG reminded me of an idea I had back when I first heard of naked objects - naked XML. The idea is that you would be to create a GUI that would let you visually edit specific XML documents using the same naked principles as the Naked Objects approach. Imagine being able to have a visual representation of everything from standard files like a good ol' web.xml to your custom in-house XML applications. A good XML editor will take you far, but I can think of a number of times where a naked objects GUI would be exactly what you are looking for.

The naked objects framework supports persistent objects, one strategy being persistence to XML. However, the naked objects XML object store is really nothing more than a internal data formal which happens to be XML. That's cool, and I'm sure it wouldn't be too hard to write a better XML object store that performed more complex XML mappings. An example might be Oracle's TopLink. (by a strange coincidence they talked about their upcoming object/XML mapping technologies last night at AJUG too) I used TopLink for a couple years, back in the Object People/Webgain days, and I'm sure their XML mapping tools will be just as good as their object relational mapping tools.

That would be an interesting approach, but it's not quite what I'm after. That would require writing all the naked objects by hand, duplicating the DTD/schema information. You could generate the naked objects from the schema a la JAXB. (keep in mind that the goal of a specific naked XML UI would be to work with a specific XML application, not arbitrary XML documents) That would be viable, but somewhat inelegant. I'm not sure if working directly from the schema would be better. You'd have to embed your naked directives into the schema, and you'd probably need more expressiveness than most XML schema systems give you. (since there are no objects with actual business logic) If you've seen something like Schematron, you'll know that very expressive schemas isn't that far fetched an idea, but you'd be cutting yourself off from working with normal DTD/schema based XML applications.

I honestly haven't sat down and thought through the possibilities. I've just kept the ideas at the back of my mind in case some day I find myself with some spare time. If only I were a university student with seemingly infinite free time.

XML + python.whitespace + perl.operators == YAML

YAML first hit my radar last february at LSSS when Dave Thomas proposed YAML as a good alternative to XML. After the conference I investigated YAML a bit and decided YAML must be some python programmer's way of getting revenge on people who don't have to spend their coding time managing whitespace.

YAML dropped out of site again, until I heard Dave Thomas once again promote YAML as an alternative to big bad XML. I've been a card carrying member of the Dave Thomas fan club ever since the Pragmatic Programmer first came out. (as a side note, this book came out almost the same time as another of my all time favorite books, The Practice of Programming by Kerninghan and Pike. I highly recommend both books) Given the source, I decided that it would be wise to once again investigate YAML to see what I'm missing.

Well, I still don't get it. The YAML syntax is confusing and difficult to read by a human. It certainly lacks the simplicity of the XML model. With whitespace being integral to the format, you'll need a YAML aware editor and generators for all but the simplest of documents. Perhaps comparing it to XML isn't quite fair. Despite being promoted by some as an alternative to XML, the YAML guys don't really appear to put YAML up as an XML replacement.

Instead they seem to see it as a data serialization format with it's own calling separate from XML. I can't think of many applications of XML that would be better served by YAML, but I'm willing to concede that others might. Even though I am not quite seeing where the value of YAML is, one of the design goals does resonate with me: YAML uses host languages' native data structures. What that means is that YAML is meant to map directly onto datastructures (lists, maps, etc...) in the language you are accessing it with. That sure beats programming to DOM.

I guess I'll get back to my XML and wait for YAML to pop up again. Maybe by then someone will publish something that would explain why I'd want to skip something as simple and neat as XML for YAML's odd mix of python's whitespace and perl's unintuitive operators.

DOM is reflection

It never really struck me how primitive DOM based XML access is until last night's AustinJUG meeting. (where Deb Ayers of BEA talked about XMLBeans) I've done a lot of direct DOM processing of XML. I've done it enough that it really doesn't phase me. I know the tricks and traps and how to get things done without the code looking like a complete and total hack. I guess I just never just stopped to think about how primitive it is.

But really, when it comes down to it, doing XML programming using DOM is like doing Java programming using reflection. Yeah, you can get the job done, and sometimes you really do need to work at that level. But most of the time you really want to be working with XML at a higer level.

XMLBeans does seem like an interesting high level approach. XMLBeans seems more advanced than JAXB, which I've always felt was a bit akward to use. Last night's talk was my first glimpse of XMLBeans, so I can't say anything more than it looks interesting. With both Apache support and BEA support, I think it might gain some momentum.

a dedicated XML box

At the last AustinXML meeting, Sarvega gave a demo of their dedicated XML boxes. The thought of a box dedicated just to doing XML seemed a bit odd at first, but I can definitely see why it might be a desirable thing. XML processing can really take a bite out of the performance of any system, and being able to offload that processing to a custom box definitely could speed things up considerably.

Apparently, the box can do blazingly fast XSLT (including intercepting HTTP responses and performing client-side XSLT rendering on behalf of the client), schema validation and document routing. They also mentioned being able to do signatures, encryption and other XML security functions but not knowing whether or not there is a market for it. All this is done on custom hardware, with custom XML processing code on top of a custom operating system.

Something I found very interesting is their configuration management is done using an eclipse plug-in. I may just be out of touch since I don't use a big heavy IDE to do java coding, but this struck me as very curious. Essentially they are using eclipse as a big client side application framework. Eclipse is to these applications what an app server is to a J2EE app. Maybe everyone is doing this now and I just have had my head in the sand, but that seems pretty neat to me.