Ionrock Dot Org

Recently I have been thinking about how you can make something "better". It is always tough because it is taking a very general concept and trying to pull concrete task from it. Specifically, I have been thinking about making ePublisher better. Fortunately, I feel qualified to be considered and ePublisher "user". Some may disagree with this, but the reality is I use it every day. Therefore, I know my suggestions are somewhat biased towards how I use the product. Of course, that may not be that bad!

One overarching issue that I think could be addressed is how to customize the XSL. Currently, we do everything in XSL, and I mean EVERYTHING! The code which kicks off an transformation is very basic. Traditionally it would look something like this:

result = TransformObject.ApplyXSLT( StylesheetFile, SourceNodeSetAsParam );

This is just pseudo code of course, but it suggests how you apply a transformation to an XML file and how you might pass in a node-set as a parameter. What we do is even simpler. Instead of passing an XML node-set that represents some document, we pass in an XML file that simply lists XML documents. The XSL is then responsible for finding the path of the actual data document we want to work with and loading it as a node-set. From a design perspective, what we have done is much more flexible because the XSL has no limitations on what it can do. It has the power to load whatever node-sets are available whereever it needs to. The downside is that every XSL file is responsible for loading node-sets, which makes the XSLs very difficult to understand and read.

I think my biggest improvement to ePublisher then would be to address this shortcoming. I believe the flexibility we provide is incredible and taking that away does not seem like a good idea. I always like the idea that someone could really hijack the format to do some amazing things. With that in mind, I would suggest a means of stubbing out the boilerplate aspects of the code so someone could have a simple means of getting to the node-set they need.

So, for example, in the XSL I would like to do something like this:

<xsl:variable name=\"vParagraphsInTOC\" select=\"wwloader:LoadNodeSet('wwdoc:ParagraphTOC')\" />

The 'wwdoc:ParagraphTOC' is something like the "type" that we currently use. I am sure we could come up with a large group of nice-to-have types that we can offer in addition to basic node-sets like the WIF. The user could even create a type from available types and resources. The downside is that things like the progress bar becomes less useful and I am not sure how we would handle checksums for the node-sets, but I think these are small issues. The log window does a better job of showing progress and it seems reasonable that whatever loads node-sets will check the corresponding physical documents for changes.

The big question is how would this make ePublisher better? Well, the biggest benefit is simpler XSLs. This would allow reasonable documentation for people to learn WebWorks specific details because there is no need for extra information in the XSLs. This might also promote better tools such as a Node Watcher that examines what nodes are available in a stage or XSL file. The biggest benefit is that people who understand XSL have a much lower entry point for making changes and debugging changes. Right now, it is very difficult to find what nodes you need and how/where you can get them. Beyond this, it is difficult to debug issues when they crop up and whether or not the approach to the problem is correct.

One thing I should make clear is that the XSLs should not really change. The code should do the same things and any sort of boiler plate or skeletons should be cascade like we do with the formats. Likewise, it would be helpful to actually be able to write out the "full" version of the XSL if needed. That way a new format could add back in the progress aspects if required before the "abridged" XSL is reached.

I am not sure if this would really make ePublisher "better" but I am sure it would make my life easier. I realize I am not the "customer" but I am definitely a user.