Spec XML and the Java 5 XSLT processor

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. 

Thanks,
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: boyerj@ca.ibm.com  http://www.ibm.com/software/

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