> I think I'd prefer having XSLT operations inside a different package than
> XPATH operations. XPATH isn't part of JAXP, so your XPATH
> support introduces additional dependancies that aren't strictly necessary
> for transformations (e.g. dom4j). My preference would be to work on
> seperate tag libraries that complement one another. Is there anything in
> your tag library that would prevent this approach?
Yes. I want to be able to combine XPath and XSLT operations together- such
as to style a fragment of a document - so the XSLT tags in XTags are
dependent on the XPath engine (dom4j right now).
> Some of the XTags
> features you mention are also present in XSL rel2, and the others could be
> merged in
Due to the XPath dependencies (e.g. dom4j) its probably best if we keep
these 2 libraries seperate for now.
XSL rel2 for just JAXP based XSLT
XTags for XSLT + XPath and the rest (<xtags:forEach>, <xtags:valueOf>
<xtags:choose> / <xtags:when> /<xtags:otherwise> and so on).
> If you don't think that's a reasonable approach, I'd just as
> soon deprecate the XSL tag library than have competing
> implementations.
> Maybe that's the way to go, but I suspect some people
> just want to do transformations.
Agreed, lets keep XSL for those who just want to do XSLT with minimal
dependencies (just JAXP).
> I suspect that the XSLT interface would
> be stronger and have more contributors as a result, and I bet so would the
> XPATH support.
I'd prefer to just have one tag library for working with XML which included
XPath and XSLT really but I agree that some may wish to only depend on JAXP.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
