Fw: Spec XML and the Java 5 XSLT processor

Below is being resent due to prior rejection based on a large attachment.

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


----- Forwarded by John Boyer/CanWest/IBM on 01/04/2007 10:51 AM -----

John Boyer/CanWest/IBM
12/19/2006 03:28 PM

To
Dan Connolly <connolly@w3.org>
cc
Norman.Walsh@sun.com, spec-prod@w3.org
Subject
Re: Spec XML and the Java 5 XSLT processor





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.

I am doing a dead simple use of the jaxp interface.  A transformer is 
created for diffspec and produces a correct html spec from my xml when I 
use java 1.4, but the same program has a weird reflection error in Java 
5... AND the crash goes away by removing only one of two templates that 
match sitem (the one that includes an XPath predicate).  Problem is that 
these templates are in xmlspec, which is imported by diffspec, and when 
one creates a transformer directly for xmlspec, Java 5 has no problem with 
the template.

Based on knowledge of the XSLT spec, there is nothing wrong with the sitem 
templates.  Based on the fact that they work in the Java 1.4 xslt 
processor and xsltproc, there is nothing wrong with the templates nor my 
use of the jaxp interface.  Based on the fact that I can make correct 
output with Java 5 if I just use xmlspec without diffspec, there is 
nothing wrong with templates in xmlspec nor in my use of the jaxp 
interface.

Moreover, I can rewrite one of the two sitem templates to eliminate the 
need for the other one, at which point Java 5 does create a transformer 
for diffspec, although it seems to create a broken one in which some of 
the templates in xmlspec are not available to apply-imports.

All of this detail is included in the prior email!!! 

And it proves the point that work must be done on spec xml to help feed 
the bug database of java 5 AND to work around existing limitations in java 
5 as the difficulties are *not* in the simple program I wrote.

As a first go that seems like a fair amount of detail.  Moreover, I didn't 
expect my prior email to be the end of the conversation, but rather the 
beginning of a conversation. From your reaction, I am guessing that you 
might be the guy who would actually work on something like this, which was 
my main question.  Thanks for volunteering :-), and since you asked for 
more details, here should be enough to at least get started...

The program I am using is



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

And the above calls are made against the XForms source, which is here: 
http://www.w3.org/MarkUp/Forms/Group/Drafts/REC-xforms-10-ongoing/xforms10.source.zip

[attachment deleted; member only link added] 

Note that the source bundle includes index-all.html and index-diff.html. 
These are the expected output, which are currently generated by 
MAKESPEC.bat by invoking a Java 1.4 processor's XSLT processor directly. 
In 1.4, the class had a main, so you could call it directly, but that main 
was removed in Java 5, so the above program is needed.

So, it is possible to generate the problem I described above by simply 
compiling applyXSLT.java (with 1.4 or 5) and then making the calls above 
*with a Java 5 processor*.   Note that your Java 5 processor must be from 
Sun and must not be infested with an XSLT processor other than the 
default, e.g. the IBM JRE does not have a problem. 

And if you comment out the template with match="sitem[position() ..." then 
you will see that the exception goes away, but the output is incorrect. In 
particular, all diff marked content disappears completely.  A little 
further debugging reveals that the diffspec templates are matching, but 
their apply-imports calls are not producing any content.

You will probably notice that xformspec.xsl has been inserted between 
diffspec and xmlspec.  I can only say I inherited this and will change it 
someday, but that it is immaterial to the problem.  The direct import of 
xmlspec by diffspec manifests the problem.

The only thing that has changed since my last email is that I found a way 
to create a dead simple version of the weird exception problem, so after I 
hit send, I might find that there is an easy way to recreate the 
apply-imports failure too.   This will help feed some immediate bugs into 
Sun, but if there are modifications that could be made to diffspec/xmlspec 
so that they work with the current Java 5 processor, that would be 
preferrable.  It also would help in figuring out whether there are any 
other issues than the two that have presented themselves so far.

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





Dan Connolly <connolly@w3.org> 
12/19/2006 01:18 PM

To
John Boyer/CanWest/IBM@IBMCA
cc
Norman.Walsh@sun.com, spec-prod@w3.org
Subject
Re: Spec XML and the Java 5 XSLT processor






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
problem.

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