Spec XML and the Java 5 XSLT processor

Previous Topic Next Topic
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view

Spec XML and the Java 5 XSLT processor

John Boyer

Hi Norman and "spec-prod",

Ian Jacobs recommended that I contact you about the following problem:

I have been having a lot of difficulty with spec XML for some time now.  I have tried to pour time into this off and on for the last two years in fact, but a day here and a day there is the most I really can get.

I am a bit of a minimalist when it comes to the tooling an author/editor should need in order to produce W3C specs.  This is because I want to be able to check into CVS a bundle of things that *anyone* can check out and immediately be able to build the spec without needing to install anything else.  I do assume Java, and that worked pretty well in the world of Java 1.4, which came with a built-in XSLT processor that could handle diffspec and xmlspec.  But I don't really like to assume that people have things like perl or their own custom xslt processor (e.g. xsltproc).

By "pretty well" I don't mean flawless, of course.  It seems that the Java 1.4 XSLT processor had trouble creating the "sliced up" version of our spec.  But since everyone considers that version to be a nuisance, I am happily only creating full specs these days.

But along came Java 5, in which Sun removed the static main from the xslt class so that it could not be called from the command line anymore.  In response, I wrote a little tool that uses the jaxp interface to properly call the xslt processor.  The idea was to have an extra small program that I could check into my source bundle that would enable spec authors to build the spec regardless of whether they had Java 1.4 or anything higher.  Since I write 99% of the spec xml right now, it's really still an 'idea' of distributing the work, but it would be nice to turn the idea into practice.

Anyway, the tool I created works great under 1.4, and for many transforms it works just fine under Java 5.  In particular, the Java 5 processor has no trouble with anything in the version of xmlspec.xsl that I use.  However, the Java 5 xslt processor completely blows up with a very weird error when attempting to create a transformer object for diffspec.  

This is problematic because both the diff-marked and the non-diff-marked versions of specs must be created with diffspec because xmlspec does not delete content marked diff="del".

I can spare you the full details here, but suffice it to say that I can prove that the error is not being caused by my code, nor is it being caused by an illegal construct in diffspec/xmlspec that "happens" to be handled by some xslt processors.  For example, by painstakingly removing all comments from xmlspec and doing a binary search for the content on which the Java 5 processor chokes, I discovered that the template matching sitem with an xpath predicate is the problem.  There is nothing wrong with the template as proven by the fact that Java 5 has no problem with it when transforming based on xmlspec, but Java 5 freaks out when it is *imported* by diffspec.

In this case, it is easy to rewrite the other sitem template in xmlspec to do the work of both templates that match sitem.  When I do this, Java 5 stops freaking out and runs the transform.  However, it does not produce correct output.  For starters, the apply-imports calls in diffspec produce *no* matching rules for any elements that have already been matched by a diffspec template because they have a diff attribute.  Irritatingly, my attempts to create smaller stylesheets that model the problems I am seeing with diffspec have not been successful.  

There are other ways of writing diffspec and xmlspec that could avoid the problems Java 5 seems to be having.  Alternately, some more concerted effort could go into diagnosing the Java 5 default xslt processor problems to the point of being able to file bug reports with Sun.  So my question is whether there is any W3C team member(s) who can work on this type of support, i.e. to further narrow the problem to file bug reports with sun as well as to modify xmlspec/diffspec as needed so that they do run with the more recent default Java xslt processors.  Now that we have Java 6, this seems like an increasingly important task for supporting the toolset needed to create W3C products.  

John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: [hidden email]  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer

Reply | Threaded
Open this post in threaded view

Re: Spec XML and the Java 5 XSLT processor

Dan Connolly

On Tue, 2006-12-19 at 11:38 -0800, John Boyer wrote:
> I can spare you the full details here,

D'oh! That's exactly what somebody would need in order
to work on the problem: enough details to reproduce the

The overall story you tell is interesting, but you left
off right before the critical part.

I can't promise that anybody will fix the problems,
but the odds seem significantly higher if you can give a
detailed problem report.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Reply | Threaded
Open this post in threaded view

Re: Spec XML and the Java 5 XSLT processor

Dan Connolly
In reply to this post by John Boyer

On Tue, 2006-12-19 at 18:28 -0500, John Boyer wrote:
> Hi Dan,
> Double D'oh!  I only spared the full details, not *all* of the
> details.  There was quite enough detail to prove the point for which I
> was sparing the reader the full details.

OK, I guess I was reading too fast.

I was looking for something that said "type this, and you'll
see the problem". I suppose we have that now, for folks
that regularly use Java. I'm not yet able to reproduce
the problem.

> I am doing a dead simple use of the jaxp interface.

I have zero experience with jaxp, so even a dead simple use
is going to take me a while to get my head around.

> Once compiled, I call it like this:
> java applyXSLT -IN index.xml -XSL diffspec.xsl -PARAM show.diff.markup
> 0 -OUT test-index-all.html
> java applyXSLT -IN index.xml -XSL diffspec.xsl -PARAM show.diff.markup
> 1 -OUT test-index-diff.html

Just to put my ignorance in full view, I tried that and failed thusly...

$ java applyXSLT -IN index.xml -XSL diffspec.xsl -PARAM show.diff.markup
0 -OUT test-index-all.htm
Exception in thread "main" java.lang.NoClassDefFoundError: applyXSLT

I guessed that's because I haven't compiled it, so I guessed
at how to compile it and failed...

$ javac applyXSLT.java
bash: javac: command not found

So I'll have to remember how to get java going on this debian
linux machine, I guess. Or maybe I'll try it on my Mac laptop.

Here's hoping... and bonus points to anybody who beats me to it...

Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E