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 Tue, 08 Feb 2000 06:52:58 GMT

> Step
> back and look at the interfaces from a user's point of view rather than
> implementor's point of view.

Yep, we've been trying.  Sometimes easier said than done... one of the
reasons to get wide review for this.

> Can the operation of an
> implementation be explained in plain English?

Can XSLT be explained in plain English?  :-)  What makes perfect sense to
me, doesn't always make sense to others.

I'm not kidding.  The XSLT process tends to be hard to convey to someone
who isn't familiar with it.  And even with people who are -- in the XSLT WG
we would constantly get tangled up with communication because many of the
meanings of the processes aren't in common usage.

> How much documentation does a first-time user have to read to understand
> abstractions? I would think the goal would be to minimize this.

Yep.  You're preaching to the choir.  After supporting LotusXSL and Xalan
for a while now, I can tell you I really really really want very easy and
understandable interfaces.  The question is how to get there.  I'll take
any help I can get!

> - Processor (possibly split into Compiler and Interpreter interfaces?)

I'm worried Compiler might be misinterpreted as Java byte code compilation,
and I'm not sure what Interpreter means.  I've considered both these.

> - Stylesheet (or maybe TransformRuleSet to avoid confusion with CSS?)

Yep, that's what everybody has as a stylesheet class.  The problem is, if
you name an interface Stylesheet, everyone has to change existing
implementations.  Maybe it's important enough to go through the pain of
this.  What do other's think?

The other slight issue is that Stylesheet is somewhat misleading. One could
argue that an XSLT transformation sheet isn't a stylesheet in itself.  But
I don't think this is a strong argument for not using it, since it is in
common usage.

> - CompiledStylesheet (if necessary)

Not sure what this would be vs. Stylesheet.

> - InputSource

SAX already uses this.  That's why it's tagged XSLTInputSource.

> - Result

Yep, perhaps better than ResultTarget.  I was trying to mirror

> Transformation and TransformContext seem to be a bit abstract.

I agree about Transformation.  TransformationContext seems to me to be very
exact.  But... what's english to me might be greek to you.

What about just "Session" or "TransformSession"?

> Threading
> issues could be considered implementation or quality-of-service details
> don't belong in the interfaces.

This I strongly disagree with.  I don't think that threading issues are
clear enough in today's interfaces.  It's very important that both
implementors and users understand threading up front, and that it is part
and parcel of the character of the class.  Good concurrency pervades
everything.  It tells you if something can be safely mutated or not, and it
tells you if you have a long or short term object.  These issues will
otherwise rise up as surprising "gotchas" during deployment, both on the
client and the server.  Even in a simple "hello world" program, you want to
users to start learning this, and getting used to it.  Anyway, that's my

> Another suggestion: take a look at Microsoft's ADO interfaces

OK.  They're not the first thing that comes to mind when I think of a good
interface, but I'll take another look upon your recommendation.

> Maybe something similar could be done with the XSL processor.  I could
> create (and parse) a stylesheet and transform an input source into a
> without the need to create a processor, compile the stylesheet, apply the
> compiled sheet to an input source, etc.  You get the idea.

The problem I run into trying to achieve this is that you start having
multiple ways to do things... and end up making a broader, more complicated

> Just my two cents as an interested observer.

Thanks!  Please keep contributing.  Somewhere here there's got to be the
perfect interface...


View raw message