DXL = All Domino design and content described in XML format as prescribed by the Domino DTD. An example of DXL is the ?ReadViewEntries View URL command we're all used to by now. As another example, this image shows the DXL that describes the design of the Contact form from the iNotes template

Here's a scenario - Somebody asks me if they can see how I designed the "All" view in a particular database. Do I a) Zip and send the whole database or b) Create a new database, copy in the "All" view and mail this database? Usually the latter. In Domino 6 there's no need. You can export the view as a DXL file and simply mail that file for the user to import at the other end.

What got me excited (not that I'll ever get round to doing anything about it) is that you can, in theory, create a Domino Designer "Lite". By this I mean something that only includes the things I use as a pure Domino developer - Forms, Subforms, Views, Pages, Fields, Agents, Computed-Text and a subset of the @Formula language. What I don't need are things like - Outlines, Navigators, Framesets, Actions, Hotspots/Buttons, Layout-Regions, Sections, Tables, Styles, Date Picket, Folder Pane, Group Scheduler etc etc. Just imagine a designer client that never crashed.

The possibilies are almost endless. It's not only design elements, you can get the DXL to every document in a database. You can search/replace these and post the result back. You could serve every page from a database from one servlet that uses Xalan to translate the DXL in to HTML that you have complete control over. If you though you could forget the whole XML thing. Think again and get learning now. I know I am..

Stephen Neal was our man at the Domino Bootcamp this week. Hopefully he'll have lots of juicy gossip. They spoke about DXL quite a bit apparently.

Comments: Disabled

Okay, so my washing-machine XSL analogy from Monday is flawed. First to point this out was Mike on our way for a sandwich yesterday. If that didn't convince me then I certainly started listening when Ned Batchelder wrote with his interpretation. Still in need of a simple analogy I can use though. Reading the abstract from the W3C's spec doesn't help any... it seems everybody has their own understanding. I suppose it doesn't really matter how you understand it as long as you can get them to do what they're supposed to ;o)

The good to come from this is that Ned has turned me on to DXL, which he designed and implemented before leaving Iris. DXL made a cameo in R5 and is to have a major role in Domino 6. The beauty is that this all ties in with what I've been playing with over the past week or so.

Tomorrow I'll briefly mention why DXL gets me excited....

Comments: Disabled

What's polluting my head at the moment: SVG, XML, XSL(T), SAX, DOM, Xerces, Xalan, XPath, XSLTC, TrAX and a few others buried beneath all these. Why? I'm trying to work out the best way to generate SVG content without the need for the Notes Java classes - just using some plain old XML instead. In doing so I've just about got to grips with what each of the above is best suited for. Soon I hope to have something I can show you all that will make it worthwhile.... don't go holding your breath on me though ;o)

It's all just a bit too much sometimes...

Comments: Disabled

Something that has always confused me is the difference between XSL and XSLT. Are they not just the same thing? Apparently not. The trouble with me is that it doesn't matter how many times I read their fancy definitions I need my own way of painting the picture in my head. Finally, I now think I have an anology that suits my simple way of thinking. Okay, think of XML as your dirty washing and XSL as your washing-powder - XSLT is the washing machine. That's to say that XSLT is simply the way in which you apply the XSL code to your XML.

If anybody thinks I'm a geek you're right. I am ;o)

Verisign!

Comments: Disabled

I know, I know, I said I'd shut up about SVG. Have a look at this though. A dynamic, interactive bar-chart built on live data from a Domino view. Watch the face of your colleagues as you show them this, adding a few more documents to the view and watching the bars grow...

How does it work? An embed element of type "image/svg+xml" is added to a form. Its source (src) being a Java servlet that computes and returns all the required SVG. Believe it or not, it's not actually that complicated when you've got to know a bit about the SVG elements involved. Honest.

Okay, so I'm teasing you now. I know what you're thinking - where's the code you fool? Show me the code! Hmmmm, not sure it's ready yet. I've been using Ethereal to track how long it takes the servlet to run with varying amounts of documents in the view. In the shot below you can see that request 189 from the browser is for the servlet "embed" at 0.321s and then the next interaction is the server's response at 0.773s - a delay of about 0.4 seconds. Nothing to worry about, I know, but this was with only a few hundred documents. Raise it to a few thousand and the delay is more like 4 seconds.

If anybody has ideas about performance gains then they are welcome to get in touch and we can work on this together. One idea I do have is that it would be better to use something like the Xerces/Xalan combination to parse a view's XML in to SVG and send that to the browser rather than having to "while loop" a whole view....

[Edit] Forgot to mention that what you can't see from this image is that the chart is interactive. Move the mouse over the bars and extra information appears about each section. Also fairly easy to do if you understand the idea of DOMs. Think DSVG.

Comments: Disabled