You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Rick Bullotta <Ri...@lighthammer.com> on 2001/01/18 16:48:28 UTC
Xalan 2.X and redirect extension...
Food for thought:
We're using the redirect extension function in a number of cases to derive
multiple output streams from a single transformation (so far, so good).
Now, the challenge is that in many cases, the content of these output
streams needs to be of a different format (some text, some XML, some HTML),
but there is no way (even with multiple xsl:output elements) to change the
output type "on the fly". An example might be processing an XML-structured
"book" and transforming it into HTML content for viewing, XML content for
indexing/searching, and something else that I can't quite think of in text
format ;>.
Along the same ends, redirect currently supports file output only. It would
be very valuable if it could support any type of output target (file, output
stream, or DOM). The obvious alternative, which isn't necessarily too
painful, is to simply perform multiple transformations. However, on very
large XML docs this can create some performance issues.
Your thoughts?
- Rick Bullotta
CTO
Lighthammer Software (www.lighthammer.com)
Re: Xalan 2.X and redirect extension...
Posted by Larry Garfield <lg...@students.depaul.edu>.
Gary L Peskin wrote:
> Larry Garfield wrote:
> >
> This idea seems to me to be a lot of fooling with the XSLT spec which
> doesn't seem like a good idea. I think it could lead to a lot of
> problems down the road. I think that what might be appropriate is to
> define a nested extension element within xalan:redirect (like
> xalan:redirect-spec) that could have all of the appropriate attributes
> from the xsl:output element as well as additional attributes to specify
> output targets. A xalan:redirect element could have multiple nested
> xalan:redirect-spec elements inside it and would process the result tree
> according to each redirect-spec.
Correct. I didn't mean screwing with the xsl namespace itself, but a tag that could
be used in place of xsl:apply-templates. A quick 'n dirty example would be something
like:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
xmlns:lxslt="http://xml.apache.org/xslt"
xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect"
extension-element-prefixes="redirect">
<xsl:template match="mynode">
<out>
<redirect:stylesheet-call src="otherscript.xsl" file="doc2.out"
match="othernode"/>
</out>
</xsl:template>
</xsl:stylesheet>
That way, you in essence are calling a template, which just happens to be an external
file, which you redirect to some other output file.
Or am I completely off-base? :-)
--
Larry Garfield
DePaul Linux Users' Group Secretary
lgarfiel@students.depaul.edu
lgarfiel@netscape.net
Do you have a PalmOS Organizer? Click here to add me to your address book:
http://signature.coola.com/?lgarfiel@students.depaul.edu
ICQ#: 6817012
AIM Name: LOLG42
-- "If at first you don't succeed, skydiving isn't for you." :-)
Re: Xalan 2.X and redirect extension...
Posted by Gary L Peskin <ga...@firstech.com>.
Larry Garfield wrote:
>
> Rick Bullotta wrote:
>
> > Food for thought:
> >
> > We're using the redirect extension function in a number of cases to derive
> > multiple output streams from a single transformation (so far, so good).
> > Now, the challenge is that in many cases, the content of these output
> > streams needs to be of a different format (some text, some XML, some HTML),
> > but there is no way (even with multiple xsl:output elements) to change the
> > output type "on the fly". An example might be processing an XML-structured
> > "book" and transforming it into HTML content for viewing, XML content for
> > indexing/searching, and something else that I can't quite think of in text
> > format ;>.
> >
> > Along the same ends, redirect currently supports file output only. It would
> > be very valuable if it could support any type of output target (file, output
> > stream, or DOM). The obvious alternative, which isn't necessarily too
> > painful, is to simply perform multiple transformations. However, on very
> > large XML docs this can create some performance issues.
> >
> > Your thoughts?
>
> That would be very useful, I believe. The main issue, at least for me, is being
> able to process a given subset of a node-tree into one file, while maintaining
> access to, for instance, ID attributes elsewhere in the original file. (So
> that, for instance, you can create cros-page hyperlink cross-references.)
>
> What if, rather than having the output switching occur inline, there was an
> alternate version of the <xsl:apply-templates> command, that called an external
> xsl stylesheet file with output redirected to a different file (or some other
> output stream)? That way you can use whatever <xsl:output> tag you want in that
> separate stylesheet, and it will process correctly, but templates in the second
> stylesheet will still have access to the entire node tree if needed. The second
> stylesheet would then also be fully self-contained and valid, so could be used
> to process the original source file for just a given sub-tree if that was all
> you wanted.
Larry --
This idea seems to me to be a lot of fooling with the XSLT spec which
doesn't seem like a good idea. I think it could lead to a lot of
problems down the road. I think that what might be appropriate is to
define a nested extension element within xalan:redirect (like
xalan:redirect-spec) that could have all of the appropriate attributes
from the xsl:output element as well as additional attributes to specify
output targets. A xalan:redirect element could have multiple nested
xalan:redirect-spec elements inside it and would process the result tree
according to each redirect-spec.
Gary
Re: Xalan 2.X and redirect extension...
Posted by Larry Garfield <lg...@students.depaul.edu>.
Rick Bullotta wrote:
> Food for thought:
>
> We're using the redirect extension function in a number of cases to derive
> multiple output streams from a single transformation (so far, so good).
> Now, the challenge is that in many cases, the content of these output
> streams needs to be of a different format (some text, some XML, some HTML),
> but there is no way (even with multiple xsl:output elements) to change the
> output type "on the fly". An example might be processing an XML-structured
> "book" and transforming it into HTML content for viewing, XML content for
> indexing/searching, and something else that I can't quite think of in text
> format ;>.
>
> Along the same ends, redirect currently supports file output only. It would
> be very valuable if it could support any type of output target (file, output
> stream, or DOM). The obvious alternative, which isn't necessarily too
> painful, is to simply perform multiple transformations. However, on very
> large XML docs this can create some performance issues.
>
> Your thoughts?
That would be very useful, I believe. The main issue, at least for me, is being
able to process a given subset of a node-tree into one file, while maintaining
access to, for instance, ID attributes elsewhere in the original file. (So
that, for instance, you can create cros-page hyperlink cross-references.)
What if, rather than having the output switching occur inline, there was an
alternate version of the <xsl:apply-templates> command, that called an external
xsl stylesheet file with output redirected to a different file (or some other
output stream)? That way you can use whatever <xsl:output> tag you want in that
separate stylesheet, and it will process correctly, but templates in the second
stylesheet will still have access to the entire node tree if needed. The second
stylesheet would then also be fully self-contained and valid, so could be used
to process the original source file for just a given sub-tree if that was all
you wanted.
--
Larry Garfield
DePaul Linux Users' Group Secretary
lgarfiel@students.depaul.edu
lgarfiel@netscape.net
Do you have a PalmOS Organizer? Click here to add me to your address book:
http://signature.coola.com/?lgarfiel@students.depaul.edu
ICQ#: 6817012
AIM Name: LOLG42
-- "If at first you don't succeed, skydiving isn't for you." :-)
Xalan2 D07, XalanJ1 compatibility bug?
Posted by Rick Bullotta <Ri...@lighthammer.com>.
It appears that calling the getStylesheet() method on an XSLTProcessor
object returns null even if a valid stylesheet has been loaded by the
processor. I noticed this when attempting to call the getOutputMediaType()
method. A null pointer exception was thrown, which I later realized was
actually a null coming back from getStylesheet. Identical code, of course,
works fine with Xalan 1.2.2. The following code is called just prior to the
getStylesheet method, and doesn't throw an exception. Perhaps the problem
is with processStylesheet?
try {
processor =
XSLTProcessorFactory.getProcessorUsingLiaisonName("org.apache.xalan.xpath.xd
om.XercesLiaison");
xsldoc = XMLHandler.getDocument(sStylesheet);
xsldocinput = new XSLTInputSource(xsldoc);
processor.processStylesheet(xsldocinput);
}
catch(Exception e){
processor = null;
mManager.getErrorHandler().addNonFatalMessage("Stylesheet [" + sStylesheet
+ "] was not found or could not be read.");
}
Regards,
Rick Bullotta
CTO
Lighthammer Software