cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <>
Subject RE: XSLT API Proposal (Draft 2)
Date Mon, 07 Feb 2000 16:55:05 GMT

Kay Michael <> wrote:
> URIResolver: resolveURI should be passed the Base URI as well as the
specified URI


> OutputProperties... has some stuff which I don't really need or want:
mine is much
more closely a direct mapping of the xsl:output properties.

This is all related to the desire to have a set of
interfaces that uses.  I do have a data-only version of the
class, which perhaps I should use until this is ironed out.

> (I even keep the
> values as yes/no strings rather than booleans, though I wouldn't defend
> strongly: it gives me the option to support additional values in a
> e.g. the <saxon:output> extension elements now permits indent="3".)

Hmm... there should probably be getAttribute(name, namespace) and
getAttributes(namespace) methods.

We could change the whole thing to be something where you could get an
interface on any xsl element, and then get the attributes for that method.
Kind of a pain to support.  Opening a Pandora's box, I think.

> XSLTExecContext. I hate the name. I have trouble with class names that
> quite so abstract, and I think users do too. I thought this class
> represented a stylesheet after compilation, in which case I would have
> called it CompiledStylesheet or ExecutableStylesheet.

Huh?  Not at all... Transform represents the compiled stylesheet.
XSLTExecContext was meant to represent a session context for the XSLT

What do you think of Karun's TransformContext idea?  If you rename
XSLTExecContext back to XSLTProcessor:

XSLTProcessor tfactory = TransformFactory.newProcessor(...);
Transform transform = tfactory.createTransform(new XSLTInputSource
Transform transform2 = tfactory.createTransform(new XSLTInputSource

for(i = 0; i < 100; i++)
  TransformContext tcontext = transform.getNewContext();
  tcontext.setIndent(true); // Assaf won't like this...
  tcontext.setParameter("foo", null, "hello");

  TransformContext tcontext2 = transform.getNewContext();
  tcontext2.setResultTarget(new XSLTResultTarget("foo"+i+".out"));

  // If TransformContext is a DocumentHandler, then pipe the results
  // of transform into transform2.
  transform.process( tcontext, new XSLTInputSource("foo.xml"),
                   new XSLTResultTarget(tcontext2));

I'm getting pretty warm to this, as it solves a number of problems,
including your comments, I think, and makes the model more clear.  It has

> My model
> is fairly simple: you start with a stylesheet expressed as a character
> stream of some kind, you compile it (once) to create an executable
> stylesheet, you can run this executable any number of times, in parallel
> you want, each time against a different source document and with
> parameters to create a different Result Tree.

This is basically my model too.

> I'm having a little difficulty
> relating this view of the world to some of the methods I see in
> XSLTExecContext and Transform.

Not sure why...

> XSLTResultTarget. I'm having a little trouble with this one too...
> I do this be supplying it with an Emitter... etc.

XSLTResultTarget supports this totally via the setDocumentHandler.  All you
need to do is have a constructor for you Emitter that takes a
OutputProperties object.  But I believe callers should also be able to just
hand in a stream, or a DOM node, and have the right thing happen, in which
case the processor would create it's own Emmitters or Formatters or

> I'd be a little inclined to try replacing XSLTResultTarget with
> an OutputMethod class.

You mean an OutputMethod implementation?  And only allow output to a class
that supported OutputMethod?

  transform.process( tcontext, new XSLTInputSource("foo.xml"),
  OutputMethod omethod = tcontext.newOutputMethod(System.out);
  transform.process( tcontext, new XSLTInputSource("foo.xml"), omethod);

Is this similar to what you had in mind?


View raw message