Re: Error Text (was RE: Checker Home Page and Regular Teleconference Details)

Hi Sean,

> On 5/17/07, Jo Rabin <jrabin@mtld.mobi> wrote
>> Yes, I see the approach, but while I don't want to give away the
>> advantages of Java message bundles, I think the XSLT would be more
>> useful if it could be run independently of the framework. E.g.  
>> isomeone decided to generate a moki document, they could then run the
>> tests in turn by calling them from an XSLT, rather than from the
>> framework.
>
> In general, this is not going to be possible. Some bits of test logic
> that I've already run into (e.g. "if X, re-request the document with
> headers Y and Z") must be delegated to helper functions. This is part
> of why I've been tilting at the XSL solution for a while... it's
> seductive but you end up with a half-way solution which has
> disadvantages of both approaches.
>
> I still think the XSL solution is clean in many cases and we should
> proceed with it, but consider the stylesheets an implementation detail
> of the framework and not take undue pain to make them independently
> usable. Where they happen to be, great.

Jo starts with the idea to use xsl:import (or include) and I add the  
idea to use XInclude.
When writing the XSLT, I noticed that the XInclude have to be  
processing AFTER the transformation in a separate process.
To keep it easy, I used the document() XPath function.

If we want to generate a fallback message (for messages not special  
implemented in the language file),
my solution is the XInclude processing in a separate process.
OK, this is all possible with XSLT, with xsl:import... xsl:variable,  
with other frameworks,
but with document() or XInclude the messages can directly handled in  
the XSLT and the messages are xml.

Attached are both versions: document() and XInclude - lets find a  
solution ;-)

  Roland