cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: Fw: XSLT API Proposal
Date Sat, 05 Feb 2000 06:38:43 GMT

(Adam of Oracle replied in private to my proposal since he doesn't
subscribe to the lists, but agreed that I could forward the note to the cc
list).

Adam, thanks so much for your insights.  Comments:

>  - Obviously, it'd be better to have this in a more "neutral"
>    package - org.xml.xslt seems a good choice.

Yep, I would like that also.  I do not speak for the xml.apache.org PMC or
constituency, who may disagree for all I know, though I suspect they are
generally on the same page as me.

>  - It's not clear to me that XSLTProcessor needs setParser()
>    methods.  Any one implementation might very well offer these,
>    but these may not be needed as core methods.

Yeah, I don't have a setParser method on the current Xalan, choosing
instead to use a "liaison" glue system. But the SAX Parser interface is a
sort of standard Parser interface with which any parser I know of can be
passed as. The underlying implementation can check for parsers it knows
about.

...though it is true that some XSLT processors may have a close coupling to
a XML parser, and not support SAX at all.

Other opinions?

>  - XSLTProcessor.setParameter() needs to specify
>    exactly what the "value" Object means.  Shouldn't this
>    just be a String for an XPath expression?

Xalan does this in addition to accepting any object. I've had a LOT of
problems with people who do setParam("foo", "hello") and expect to see
their variable set to the string "hello".  It is counter-intuitive.  I
would rather see a setParamExpression method.

As for the meaning of the "value" object, you should be able to pass in any
Java object... it's up to the processor to do necessary coercion, and the
stylesheet writer to properly use the variable.  See my note to Mike Kay on
this subject also.

>  - XSLTProcessor may need a reset method to clear parameters.
>    Without it, anyone using parameters is pretty much going to
>    have to create a new instance every time.  They're supposed
>    to be cheap to create, so this isn't a huge deal.

Yes, I thought about this.  Xalan has a reset method.  I was worried that
doing reset would complicate things, but then the reset in Xalan is doing
more than what you are proposing.  I'll add this.

>  - I'd remove the XSLTResultTarget fileName methods.  It's
>    beyond trivial to get a Writer or OutputStream from a file
>    name, so this doesn't seem to buy much.

You're right, I think.  I would be happy enough to do this.  Does anyone
disagree?

>  - I'm a big fan of minimal interfaces, so I'd probably
>    delete the two-argument form of Transform.process(),
>    using processor==null for that functionality.

I find that people get confused by passing in null, and the code tends to
be less readible.  But I don't have deep feelings about this.  Anyone else?

-scott




                                                                                         
                         
                    Adam Winer                                                           
                         
                    <awiner@us.or        To:     Steve Muench <smuench@us.oracle.com>,
Scott_Boag@lotus.com        
                    acle.com>            cc:     kkarun@us.oracle.com, Steve Cave <scave@uk.oracle.com>,
          
                                         bcchang@us.oracle.com                           
                         
                    02/04/00             Subject:     Re: Fw: XSLT API Proposal          
                         
                    02:37 PM                                                             
                         
                                                                                         
                         
                                                                                         
                         




On Thu, 3 Feb 2000, Steve Muench wrote:

> Guys,
>
> any thoughts on these apis ?

Scott,

(The below comments represent my own opinion, not that of Oracle as a
whole or our XML team, etc...)

A few quick notes:
  - Obviously, it'd be better to have this in a more "neutral"
    package - org.xml.xslt seems a good choice.

  - I'm in complete agreement with the thread safety requirements
    placed on the interfaces.

  - It's not clear to me that XSLTProcessor needs setParser()
    methods.  Any one implementation might very well offer these,
    but these may not be needed as core methods.

  - XSLTProcessor.setParameter() needs to specify
    exactly what the "value" Object means.  Shouldn't this
    just be a String for an XPath expression?

  - XSLTProcessor may need a reset method to clear parameters.
    Without it, anyone using parameters is pretty much going to
    have to create a new instance every time.  They're supposed
    to be cheap to create, so this isn't a huge deal.

  - I'd remove the XSLTResultTarget fileName methods.  It's
    beyond trivial to get a Writer or OutputStream from a file
    name, so this doesn't seem to buy much.

  - I'm a big fan of minimal interfaces, so I'd probably
    delete the two-argument form of Transform.process(),
    using processor==null for that functionality.

Regards,
Adam Winer
awiner@us.oracle.com
Oracle Corp.







Mime
View raw message