Re: XSLT Reuse (Was: Even if you're not ... (Was: If you're going to the W3C meeting in March))

[Peter Hunsberger <peter.hunsberger@gmail.com>]

On Wed, 2 Feb 2005 09:36:41 -0500, Alan Gutierrez
<alan-xml-dev@engrm.com> wrote:
> * Peter Hunsberger <peter.hunsberger@gmail.com> [2005-01-31 10:51]:
> > On Sat, 29 Jan 2005 10:02:17 -0500, Alan Gutierrez
> > <alan-xml-dev@engrm.com> wrote:
> >
> > <snip/>

<snip>some discussion on somewhat different issue</snip

>    This system is building Ant files. I've reduced my Ant needs to
>    dependency resolution.
> 
>    To start with, if antlr needs javac, it is on the developer to
>    know this, and request both task definitions. There is no fancy
>    include mechanism that resolves dependencies.
> 
>    Then it becomes a matter of sorting out the dependencies. I'd
>    like an antlr task, when it generates it's targets, to be able
>    to say that javac now dependes on antlr.
> 
>    This is something to solve in XSLT.
> 
>    My first attempt will be to generate an ant file that looks like
>    this:
> 
>    <project name="foo" default="java">
> 
>      <target name="antlr">
>        <dependant>javac</dependant>
>        <antlr grammar="src/main/antr/Foo.g"/>
>      </target>
> 
>      <target name="javac">
>        <javac srcdir="src/main/java/**/*.java"
>               destdir="var/classes/main/classes"/>
>      </target>
> 
>    </project>
> 
>    Then, and here I'm using a pipelineing approach, I'd run an XSLT
>    transform that would make it look like this:
> 
>    <project name="foo" default="java">
> 
>      <target name="antlr">
>        <antlr grammar="src/main/antr/Foo.g"/>
>      </target>
> 
>      <target name="javac" depends="antlr">
>        <javac srcdir="src/main/java/**/*.java"
>               destdir="var/classes/main/classes"/>
>      </target>
> 
>    </project>
> 
>    Which ought to be simple enough.
> 
>    Basically, the antlr XSLT will add dependencies to the javac task.
> 
>    That's about all I think I need to worry about for extensiblity
>    in this particular problem.
> 
>    So maybe one way to solve XSLT reuse is through pipelining and
>    the generation of intermediate documents.

Ok, I think I misunderstood your original question; I thought you
where asking how to make one of your XSLTs into a generic framework
type of file that can be reused by other people.

It seems you are perhaps instead asking how to use other people's XSLT
in a framework of your own?  If so, yes, I agree pipelines are an
excellent way to do this; you can wrap an XSLT on either or both sides
using a pipeline.

We use Cocoon for this purpose, but we don't adapt external XSLT/XML. 
Rather we produce a sort of canonical form abstract object model from
various combinations of data sources.  We can then map this to various
output representations, the standard N inputs to M outputs kind of
issue. As long as some XSLT can convert the output of something into
the standard object model then the output XSLT can use it for other
purposes...

-- 
Peter Hunsberger