Saxon

I'm sorry, but StyleElement was never intended as an external interface, and if your application is calling it then it's very likely it will have to change. Exactly how it changes depends on what it's doing, and I can't tell that from a brief description, I would need to see your actual code. And since Saxon 6.5 is a very distant memory (over ten years now!), it would probably take me just as long to find out the answer as it would take you.

Thanks for a quick response Michael :)

Here is the sample code snippet.. Basically we have a bunch of Extension elements (like CheckAvailabilityElement) which extend from StyleElement.

import com.icl.saxon.Context; import com.icl.saxon.expr.Expression; import com.icl.saxon.style.StyleElement;

public class CheckAvailabilityElement extends StyleElement {

//some other methods//

public void process(final Context aContext) throws BusinessException
{
    boolean result = true;
    final String availabilityString =
        evaluateExpressionAsString(this.availability, aContext, false);
	
	// some additional logic
}


protected String evaluateExpressionAsString(
    final Expression anExpression, final Context aContext, final boolean isRequired)
    throws BusinessException
{
    //---------------------------------------------------------------------------
    // The expression may be null if and only if optional flag has been specified
    //---------------------------------------------------------------------------
    if (anExpression == null)
    {
        if (isRequired)
        {
            final String message = "Null expression is not allowed";
            
            //If the expression is null, then throw error
            final BusinessException exception = styleError(message);
            throw exception;
        }
        else
        {
            return null;
        }
    }


    //------------------------
    // Evaluate the expression
    //------------------------
    final String result;
    try
    {
        result = anExpression.evaluateAsString(aContext);
    }
    catch (final XPathException anException)
    {
        final String message = "Error evaluating expression";
        throw new BusinessException(message, this, anException);
    }


    //--------------------------------
    // Check for empty or null results
    //--------------------------------
    if ((result == null) || (result.length()) == 0)
    {
        if (isRequired)
        {
            final String message =
                "Required expression evaluated to an empty value: " + anExpression.toString();
            final BusinessException exception = styleError(message);
            throw exception;
        }
        else
        {
            return null;
        }
    }

    return result;
}

//some other methods//

}

the inline code was not uploaded properly hence attaching a file..

Throwing the exception should be a trivial change: just replace throw(syleError(x)) with compileError(x).

I suspect that converting an implementation of XSLT extension elements from 6.5 to 9.5 will involve more substantial change than that, however, since creating extension elements has always required use of fairly intimate internal Saxon interfaces. Without going back to the 6.5 code myself however, it's hard to know exactly where the issues will be.

I was a bit confused because compileError documentation says "Report a static error in the stylesheet". For me, the error is not in the stylesheet but rather in the input source (xml). Also, not sure what "static" means..

I also wanted to check whether it is feasible to have Saxon-9.x with XSLT1.0 and XPath1.0

Yes, this is just a tip of the iceberg, there will be a lot more to follow :(

Will keep troubling you whenever I get stuck..

Thanks a lot, appreciate your help :)

Cheers, Mandar

Ah yes - now I'm reminded. In Saxon 6, the stylesheet tree (containing StyleElement instances) was still around at execution time. This changed completely somewhere down the line so that StyleElement now has a compile() method which generates an Instruction object from the StyleElement. This allows the instruction/expression tree to be reorganized by the optimizer in a way that was not possible when it was all tied to the original source XML tree structure. This of course complicates things for people implementing extension elements. I'd advise you to take a look at how the SQL extension elements (e.g. SQLInsert) have changed to accomodate this redesign.

Yes, that explains the "compile" related methods added to StyleElement.. I'll look into the SQL Insert design

So should I go ahead and use compileError(x) as a replacement of styleError(x) ?

Regards, Mandar

I think the exceptions in your code are run-time (dynamic) errors, so you should throw an XPathException.

thanks :)